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Preface 



Adopte et standardise par l'Object Management Group depuis 1997, UML est 
aujourd'hui un outil de communication incontournable, utilise sur des centaines de 
projets de par le monde ; en consequence, la connaissance d'UML est desormais 
une des competences qui sont exigees quasi systematiquement lors d'un recrute- 
ment. Pourtant, trop nombreux sont encore les concepteurs qui s'imaginent, a tort, 
posseder cette competence parce qu'ils connaissent la representation graphique 
d'une classe d'association, d'une activite ou d'un etat, tandis qu'ils ne savent pas 
expliquer ni defendre leur emploi dans un modele, meme simple. C'est que, malgre 
la rigueur apportee a la specification d'UML, il y a parfois differentes f aeons de 
representer une meme idee, ou, a 1' inverse, une idee donnee pourra etre representee 
avec plus ou moins de precision selon que Ton aura utilise telle ou telle particularite 
syntaxique d'UML. 

Si Ton trouve aujourd'hui plethore de formations a UML, il faut bien reconnaitre que 
la plupart d'entre elles se trompent d'objectif . L'enseignement d'UML en tant que tel 
ne presente pas plus de difficulte ni d'interet que l'enseignement de n'importe quel 
autre langage de modelisation. Toutefois, ce qui importe en la matiere, c'est d'ensei- 
gner efficacement les principes qui sous-tendent une demarche objet dediee a 
l'analyse et a la conception de systemes complexes, mais aussi qu'un emploi judi- 
cieux des elements syntaxiques d'UML permette une representation pertinente des 
concepts metier et des choix de conception. C'est ce defi que Valtech Training releve 
avec succes grace a Pascal Roques et a ses collegues concepteurs de cours. 

Consultant experimente et pionnier de l'utilisation d'UML en France, Pascal est 
aussi un excellent concepteur de cours et un formateur a la pedagogie sans faille. II 
n'en est pas non plus a son premier coup d'essai en tant qu'auteur. Apres UML 2 en 
action, il nous livre maintenant UML 2 par la pratique, un excellent recueil de 
modeles UML issus de projets reels, ou construits pour des etudes de cas, et 
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minutieusement commentes. Le caractere unique de ce livre reside dans la mise par 
ecrit de commentaires essentiels, qui visent a expliquer un choix de modelisation et 
qui, generalement, ne sont donnes que par oral sur le « terrain ». Le lecteur pourra 
ainsi revenir a loisir sur ce qui lui fait souvent defaut, par exemple la justification de 
l'emploi de tel ou tel trait syntaxique plutot qu'un autre pour representer une idee 
particuliere. La mise en parallele de solutions « alternatives » permet egalement de 
comprendre les avantages d'une modelisation sur une autre et la precision seman- 
tique apportee par la solution choisie. 

C'est toute la puissance d'expression d'UML 2.0 et la completude de sa syntaxe qui 
sont demontrees par l'exemple dans cet ouvrage pragmatique et tres accessible, que 
le lecteur, j'en suis certain, prendra plaisir comme moi a lire d'un bout a l'autre. Je 
me permets cependant de recommander de bien realiser les exercices complemen- 
taires, excellents travaux pratiques, mais aussi remarquables tests d'auto-evaluation. 
En couvrant tous les aspects de 1' analyse et de la conception orientee objet, Pascal 
Roques illustre et explique les variations possibles dans l'usage d'UML pour 
chacune de ces etapes. 

En tant que responsable de la definition de l'offre formation chez Valtech Training, 
j'ai longtemps eu beaucoup de difficulte a recommander un livre qui serait un bon 
complement a nos formations a la modelisation objet avec UML. Merci Pascal, 
grace a la qualite pedagogique de ton livre, UML 2 par la pratique, cette tache est 
aujourd'hui considerablement plus simple. . . 



Gael Renault 
Directeur pedagogique 
Valtech Training 
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Introduction 



Objectifs du livre 



Depuis quelques annees, les ouvrages sur le langage UML et la modelisation objet se 
sont multiplies. De Merise a UML 1 , UML et SQL 2 , Bases de donnees avec UML?, etc., 
represented autant de sujets interessants pour les professionnels de l'informatique. 

Cependant, ma pratique de la formation (plus d'un millier de personnes formees a 
OMT, puis UML, depuis 1993. . .) m'a convaincu qu'il existait encore un besoin qui 
n'est pas couvert par la multitude d'ouvrages disponibles actuellement : un livre 
d'exercices corriges 4 . Je consacre en effet de plus en plus de temps pendant les 
sessions que j'anime a des seances de discussion avec les stagiaires sur les merites 
compares de telle ou telle solution de modelisation. Et je suis intimement persuade 
que ces periodes d'interactivite sur des sujets concrets ont un impact bien plus 
durable pour eux que la presentation theorique des subtilites du formalisme UML ! 

Cela m'a amene a constituer une importante base de donnees d'exercices, tires pour la 
plupart de formations, presentes ou passees, proposees par la societe Valtech Training. 
Je me suis egalement inspire des livres fondamentaux qui m'ont aide personnellement 
dans mon approfondissement de ce sujet, en particulier celui de J. Rumbaugh sur 
OMT 5 (l'un des premiers a proposer des exercices apres chaque chapitre de presenta- 
tion) et le best-seller de C. Larman 6 sur l'analyse et la conception objet. 

1 . De Merise a UML, N. Kettani et al., Eyrolles, 1998. 

2. UML et SQL : Conception de bases de donnees, C. Soutou, Eyrolles, 2002. 

3. Bases de donnees avec UML, E.Naiburg R.Maksimchuk, Campus Press, 2002. 

4. Mon idee semble avoir fait des emules depuis la parution de la premiere edition en 2001 , puisqu'un deuxieme livre du 
meme type est paru recemment : Exercices corriges d'UML, Ellipses, 2005. 

5. Object-Oriented Modeling and Design, J. Rumbaugh et al.. Prentice Hall, 1991. Une version mise a jour est parue der- 
nierement en francais, sous le titre : Modelisation et conception orientees objet avec UML2, Pearson Education, 2005 
(mais la magie ne semble plus operer comme la premiere fois. . .). 

6. Applying UML and Patterns, C. Larman, Prentice Hall, 1997. La troisieme edition de cet ouvrage a ete traduite en fran- 
cais : UML 2 et les Design Patterns, Campus Press, 2005. 
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C'est ce materiel pedagogique, fonde sur des heures de discussions enrichissantes 
avec des stagiaires de tous horizons, que je voudrais partager aujourd'hui avec vous. 
Par leurs questions et leurs propositions, ils m'ont force a prendre en compte les 
points de vue les plus divers sur un meme probleme de modelisation, a ameliorer 
mon argumentation et parfois a envisager de nouvelles solutions auxquelles je 
n'avais absolument pas pense ! 

II est a noter que cette cinquieme edition incorpore de nombreux exercices supple- 
mentaires portant sur les nouveaux concepts et diagrammes issus de la version 2 
d'UML 7 . La portee de ces ajouts couvre aussi bien le nouveau diagramme structurel 
appele « diagramme de structure composite » 8 , que les nombreuses innovations 
dans les diagrammes dynamiques 9 . Retrouvez sur le rabat de la couverture une carte 
de reference regroupant les principaux schemas UML 2 utilises dans ce livre. 



Structure de l'ouvrage 



Pour ne pas melanger les problemes, le livre est decoupe suivant les trois points de 
vue classiques de modelisation : fonctionnel, statique et dynamique, en insistant 
pour chacun sur le ou les diagrammes UML preponderants (les diagrammes entre 
parentheses sont moins detailles que les autres). 

Fonctionnel 



7. 



3 Axes de 
modelisation 



Diagramme de Cas d'utilisation 
(Diagramme de Sequence) 
(Diagramme d'Activite) 




Statique 

Diagramme de Classes 
Diagramme de Packages 
(Diagramme d'Objets) 
Diagramme de Structure Composite 
(Diagramme de Deploiement) 



Dynamique 

Diagramme d'Etats 
Diagramme d'Activite 
Diagramme de Sequence 
(Diagramme de Communication) 



J'ai utilise comme reference pour ce livre la toute derniere specification de l'OMG, a savoir le document 06-04-02 : 
UML 2.1 Superstructure. 

8. Voir en particulier le chapitre 4. 

9. Voir surtout le chapitre 6. 
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Les trois premieres parties du livre correspondent done chacune a un point de vue de 
modelisation. Pour chaque partie, une etude de cas principale, specifique, sert de 
premier chapitre. Avant l'etude de cas, on trouve un rappel des principales definitions 
utilisees dans la partie concernee. Des exercices complementaires et un recapitulatif 
des conseils methodologiques se trouvent dans un deuxieme chapitre. 

La quatrieme partie contient plusieurs etudes de cas. La premiere, tres detaillee, 
prend bien sur en compte les trois points de vue precites, mais couvre egalement en 
amont la modelisation metier, et en aval la programmation en Java et C# ! La 
derniere etude de cas aborde le sujet passionnant des design patterns. 

Une table des matieres condensee est donnee ci-apres. 

PARTIE I : POINT DE VUE FONCTIONNEL 

Chapitre 1 : Etude de cas 

Chapitre 2 : Exercices corriges et conseils methodologiques 

PARTIE II : POINT DE VUE ST ATI QUE 
Chapitre 3 : Etude de cas 

Chapitre 4 : Exercices corriges et conseils methodologiques 

PARTIE III : POINT DE VUE DYNAMIQUE 

Chapitre 5 : Etude de cas 

Chapitre 6 : Exercices corriges et conseils methodologiques 
PARTIE IV : CONCEPTION 

Chapitre 7 : Etude de cas complete : de la modelisation metier a la 

conception detaillee en Java ou C# 
Chapitre 8 : Etudes de cas complementaires 

ANNEXES 

Correspondances UML - Java - C# 

Glossaire 

Bibliographic 

Conventions typographiques 



Pour apporter plus de clarte dans la lecture de ce livre, les exercices et les solutions 
sont mis en evidence par des polices de caracteres et des symboles graphiques diffe- 
rents de la facon suivante : 
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EXERCICE 1-1, 

Les acteurs 



Identifiez les acteurs du GAB. 



— Quelles sont les entites externes qui interagissent directement avec le GAB ? 

Considerons lineairement les phrases de l'enonce. 

Pour guider un peu plus le lecteur, les questions ont un niveau de difficulte evalue de 
un a quatre, et represente graphiquement : 

question facile, 



question moyenne, 



question assez difficile mettant en jeu des concepts UML avances, 



question difficile necessitant une argumentation complexe. 



De facon ponctuelle, pour rompre la monotonie du texte, j'ai egalement utilise des 
encadres « A retenir » pour isoler une note sur une question d'un niveau avance : 

A retenir REPRESENTATIONS GRAPHIQUES D'UN ACTEUR 

La representation graphique standard de I'acteur en UML est I'icone 
appelee « stick man », avec le nom de I'acteur sous le dessin. On peut 
egalement montrer un acteur sous la forme rectangulaire d'une classe, 
avec le mot-cle «actor». Une troisieme representation (interme- 
diaire entre les deux premieres) est egalement possible, comme indique 
ci-apres. 



Introduction 
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Chapitre 

1 



Moderation fonctionnelle : 

etude de cas 



4-1 

O 



\es 



■ Acteur ■ Contexte statique ■ Cas d'utilisation ■ Acteur 
principal, acteur secondaire ■ Diagramme de cas d'utili- 
sation ■ Scenario, enchainement ■ Fiche de description 
d'un cas d'utilisation ■ Diagramme de sequence systeme 

■ Diagramme d'activite ■ Inclusion, extension et genera- 
lisation de cas d'utilisation ■ Generalisation/specialisa- 
tion d'acteurs ■ Package de cas d'utilisation . Interaction 
Overview Diagram. 



Ce chapitre va nous permettre d'illustrer pas a pas, sur une 
premiere etude de cas, les principales difficultes liees a la 
mise en oeuvre de la technique des cas d'utilisation. 

Apres avoir identifie les acteurs qui interagissent avec le sys- 
teme, nous y developpons un premier modele UML de haut 
niveau, pour pouvoir etablir preeisement les frontieres du 
systeme. Dans cette optique, nous apprenons a identifier les 
cas d'utilisation et a construire un diagramme reliant les 
acteurs et les cas d'utilisation. Ensuite, nous precisons le point 
de vue fonctionnel en detaillant les differentes facons dont 
les acteurs peuvent utiliser le systeme. A cet effet, nous 
apprenons a rediger des descriptions textuelles de cas d'utili- 
sation, ainsi qu'a dessiner des diagrammes UML complemen- 
taires (comme les diagrammes de sequence ou d'activite). 



Point de vue fonctionnel 



Premiere partie 



Principes et definitions de base 



ACTEUR 



Un acteur represente un role joue par une entite externe (utilisateur humain, dispositif 
materiel ou autre systeme) qui interagit directement avec le systeme etudie. 

Un acteur peut consulter et/ou modifier directement l'etat du systeme, en emettant et/ou 
en recevant des messages susceptibles d'etre porteurs de donnees. 

Comment les identifier ? 

Les acteurs candidats sont systematiquement : 

• les utilisateurs humains directs : faites done en sorte d'identifier tous les profils 
possibles, sans oublier l'administrateur, l'operateur de maintenance, etc. ; 

• les autres systemes connexes qui interagissent aussi directement avec le systeme 
etudie, souvent par le biais de protocoles bidirectionnels. 

Comment les representer ? 

La representation graphique standard de l'acteur en UML est l'icone appelee stick man, 
avec le nom de l'acteur sous le dessin. On peut egalement figurer un acteur sous la forme 
rectangulaire d'une classe, avec le mot-cle «actor». Une troisieme representation 
(intermediaire entre les deux premieres) est egalement possible avec certains outils, 
comme cela est indique ci-apres. 



Une bonne recommandation consiste a faire prevaloir l'utilisation de la forme graphique 
du stick man pour les acteurs humains et une representation rectangulaire pour les 
systemes connectes. 



Un cas a" utilisation (« use case ») represente un ensemble de sequences d'actions qui 
sont realisees par le systeme et qui produisent un resultat observable interessant pour un 
acteur particulier. 



Figure 1-1. 

Representations 
graphiques 
possibles 
d'un acteur 




CAS D'UTILISATION 



Modelisation fonctionnelle : etude de cas 



Chapitre 1 



Chaque cas d'utilisation specifie un comportement attendu du systeme considere 
comme un tout, sans imposer le mode de realisation de ce comportement. II permet de 
decrire ce que le futur systeme devra faire, sans specifier comment il le fera. 

Comment les identifier ? 

L'objectif est le suivant : l'ensemble des cas d'utilisation doit decrire exhaustivement les 
exigences fonctionnelles du systeme. Chaque cas d'utilisation correspond done a une 
fonction metier du systeme, selon le point de vue d'un de ses acteurs. 

Pour chaque acteur, il convient de : 

• rechercher les differentes intentions metier avec lesquelles il utilise le systeme, 

• determiner dans le cahier des charges les services fonctionnels attendus du 
systeme. 

Nommez les cas d'utilisation par un verbe a l'infinitif suivi d'un complement, du point 
de vue de 1' acteur (et non pas du point de vue du systeme). 

Comment les analyser ? 

Pour detailler la dynamique du cas d'utilisation, la procedure la plus evidente consiste a 
recenser de facon textuelle toutes les interactions entre les acteurs et le systeme. Le cas 
d'utilisation doit avoir un debut et une fin clairement identifies. II faut egalement 
preciser les variantes possibles, telles que le cas nominal, les differents cas alternatifs et 
d'erreur, tout en essayant d'ordonner sequentiellement les descriptions, afin d'ameliorer 
leur lisibilite. 



Comment les representer ? 

Le diagramme de cas d'utilisation est un schema qui montre les cas d'utilisation (ovales) 
relies par des associations (lignes) a leurs acteurs (icone du « stick man », ou representa- 
tion graphique equivalente). Chaque association signifie simplement « participe a ». Un 
cas d'utilisation doit etre relie a au moins un acteur. 



Figure 1-2. 

Diagramme de cas 
d'utilisation 




Acteur humain 1 



Sujet 



o 



Cas d'utilisation 1 



O- 



Cas d'utilisation 2 



«actor» 
Acteur non -humain 



Acteur humain 2 



Point de vue fonctionnel 



Premiere partie 



Une fois les cas d'utilisation identifies, il faut encore les decrire ! 



SCENARIO 



Un scenario represente une succession particuliere d'enchainements, s'executant du 
debut a la fin du cas d'utilisation, un enchainement etant l'unite de description de 
sequences d'actions. Un cas d'utilisation contient en general un scenario nominal et 
plusieurs scenarios alternatifs (qui se terminent de facon normale) ou d'erreur (qui se 
terminent en echec). 

On peut d'ailleurs proposer une definition differente pour un cas d'utilisation : 
« ensemble de scenarios d'utilisation d'un systeme relies par un but commun du point de 
vue d'un acteur ». 



Figure 1-3. 

Representation 
des scenarios 
d'un cas 
d'utilisation 



enchainements 



debut 



fin 
normale 



La fiche de description textuelle d'un cas d'utilisation n'est pas normalised par UML 
Nous preconisons pour notre part la structuration suivante : 



Sommaire 

d'identification 

(obligatoire) 


Inclut titre, resume, dates de creation et de modification, 
version, responsable, acteurs... 


Description des scenarios 
(obligatoire) 


Decrit le scenario nominal, les scenarios (ou enchainements) 
alternatifs, les scenarios (ou enchainements) d'erreur, mais aussi 
les preconditions et les postconditions. 


Exigences non- 

fonctionnelles 

(optionnel) 


Ajoute, si c'est pertinent, les informations suivantes : frequence, 
volumetrie, disponibilite, fiabilite, integrite, confidentialite, 
performances, concurrence, etc. Precise egalement les 
contraintes d'interface homme-machine comme des regies 
d'ergonomie, une charte graphique, etc. 
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Etude d'un guichet automatique de banque 



a 



Cette etude de cas concerne un systeme simplifie de Guichet Automatique de Banque 
(GAB). Le GAB offre les services suivants : 

1. Distribution d'argent a tout Porteur de carte de credit, via un lecteur de carte et un 
distributeur de billets. 

2. Consultation de solde de compte, depot en numeraire et depot de cheques pour les 
clients porteurs d'une carte de credit de la banque adossee au GAB . 

N'oubliez pas non plus que : 

3. Toutes les transactions sont securisees. 

4. II est parfois necessaire de recharger le distributeur, etc. 

A partir de ces quatre phrases, nous allons progressivement : 

• identifier les acteurs ; 

• identifier les cas d'utilisation ; 

• construire un diagramme de cas d'utilisation ; 

• decrire textuellement les cas d'utilisation ; 

• completer les descriptions par des diagrammes dynamiques ; 

• organiser et structurer les cas d'utilisation. 

L'enonce precedent est volontairement incomplet et imprecis, comme il en est dans les pro- 
jets reels !! 

Notez egalement que le probleme et sa solution sont bases sur I'utilisation de cartes a puce 
dans le contexte des systemes bancaires francais. Si le GAB que vous avez I'habitude d'utiliser 
ne fonctionne pas exactement comme le notre, ce n'est pas tres important. C'est surtout un pre- 
texte pour vous montrer comment raisonner fonctionnellement avec les cas d'utilisation UML. 



Etape 1 - Identification des acteurs du GAB 

Exercice 1-1. 
Les acteurs 



Identifiez les acteurs du GAB. 



Quelles sont les entites externes qui interagissent directement avec le GAB ? 
vJ^ Considerons lineairement les phrases de l'enonce. 



Point de vue fonctionnel 

Premiere partie 

La phrase 1 nous permet d'identifier immediatement un premier acteur 
evident : tout « Porteur de carte». II pourra uniquement utiliser le GAB pour 
retirer de 1' argent avec sa carte. 

En revanche, attention : le lecteur de carte et le distributeur de billets font partie 
du GAB. lis ne peuvent done pas etre considered comme des acteurs ! Vous 
pouvez noter ici que 1'identification des acteurs oblige a fixer precisement la 
frontiere entre le systeme a l'etude et son environnement. Si nous restreignions 
1 'etude au systeme de controle-commande des elements physiques du GAB, le 
lecteur de carte et le distributeur de billets deviendraient alors des acteurs. 

Autre piege : la carte bancaire elle-meme est-elle un acteur ? La carte est bien 
externe au GAB , et elle interagit avec lui. . . Pourtant, nous ne recommandons 
pas de la repertorier en tant qu' acteur, car nous appliquons le principe 
suivant : eliminer autant que possible les acteurs « physiques » au profit des 
acteurs « logiques ». L' acteur est celui qui beneficie de l'utilisation du sys- 
teme. C'est bien le Porteur de carte qui retire de l'argent pour le depenser 
ensuite, pas la carte ! 

La phrase 2 identifie des services supplementaires qui ne sont proposes 
qu'aux clients de la banque porteurs d'une carte de credit de cette derniere. II 
s'agit done d'un profil different du precedent, que nous materialisons par un 
deuxieme acteur, appele Client banque 1 . 

La phrase 3 nous incite a prendre en compte le fait que toutes les transactions 
sont securisees. Mais securisees par qui? Pas par le GAB. II existe done 
d'autres entites externes qui jouent le role de Systeme d'autorisation et avec 
lesquelles le GAB communique directement. Une interview de l'expert metier 
est necessaire, pour nous permettre d'identifier deux acteurs differents : 

• le Systeme d'autorisation global Carte Bancaire, pour les transactions de 
retrait ; 

• le Systeme d'information de la banque, pour autoriser toutes les transac- 
tions effectuees par un client avec sa carte de la banque, mais egalement 
pour acceder au solde des comptes. 

Enfin, la phrase 4 nous rappelle qu'un GAB necessite egalement des actions de 
maintenance, telles que le rechargement en billets du distributeur, la recuperation 
des cartes avalees, etc. Ces actions de maintenance sont effectuees par un nouvel 
acteur, que nous appellerons pour simplifier : Operateur de maintenance 1 . 

1. II faudrait parler en toute rigueur de « Porteur de carte client de la banque », mais c'est un peu long, d'ou la necessite 
absolue de documenter tout element UML, y compris les acteurs. 

2. Nous pourrions par exemple identifier un acteur supplemental appele « Convoyeur » ou « Gabiste », charge specifi- 
quement de remplir la caisse du GAB. 
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Plutot que de repertorier simplement les acteurs textuellement, on peut realiser 
un premier diagramme que nous appelons diagramme de contexte statique. II 
suffit pour cela d'utiliser un diagramme de classes dans lequel chaque acteur est 
relie par une association a une classe centrale unique representant le systeme, 
ce qui permet en outre de specifier le nombre d'instances d'acteurs connectees 
au systeme a un moment donne. 

Bien que ce diagramme ne fasse pas partie des diagrammes UML 
« officiels », nous l'avons tres souvent trouve utile dans notre experience des 
projets reels. 



Elaborez le diagramme de contexte statique du GAB. 



O Le GAB est un systeme fondamentalement mono-utilisateur : a tout instant, il 
O n'y a qu'une instance de chaque acteur (au maximum) connectee au systeme. 




EXERCICE 1-2. 

Diagramme de contexte statique 



Figure 1-4. 

Diagramme de contexte 
statique du GAB 




'Client banque 



systeme 



Operateur de 
maintenance 



association 




«actor» 
Sys. Auto. 



0..1 



«actor» 
SI banque 



II faudrait en toute rigueur ajouter une note graphique pour indiquer qu'en outre les 
acteurs humains Client banque et Porteur de carte sont mutuellement exclusifs, ce qui 
n'est pas implicite d'apres les multiplicites des associations. 



Point de vue fonctionnel 



Premiere partie 



Figure 1-5. 

Diagramme de contexte 
statique du GAB complete 



contrainte 



Porteur de carte 




Client banque 




«actor» 
Sys. Auto. 



Une autre solution, un peu plus elaboree, consiste a considerer que Client 
banque est une specialisation de Porteur de carte, comme cela est illustre sur 
la figure suivante. Le probleme precite d'exclusivite est ainsi resolu par cons- 
truction, grace a 1' heritage entre acteurs. 



Figure 1-6. 

Version plus elaboree du 
diagramme de contexte 
statique du GAB 




0..1 



«actor» 
SI banque 



0.1 



Porteur de carte 

A 



0..1 



Operateur de 
maintenance 



Client banque 
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Etape 2 - Identification des cas d'utilisation 



Exercice 1-3. 
Cas d'utilisation 

Preparez une liste preliminaire des cas d'utilisation du GAB, par acteur. 

O Reprenons un a un les cinq acteurs et listons les differentes facons qu'ils ont 
"o d'utiliser le GAB : 

^ Porteur de carte : 

• Retirer de 1' argent. 

Client banque : 

• Retirer de 1' argent (a ne pas oublier !). 

• Consulter le solde de son compte courant. 

• Deposer du numeraire. 

• Deposer de 1' argent (du numeraire ou des cheques) 3 . 

Operateur de maintenance : 

• Recharger le distributeur. 

• Maintenir l'etat operationnel (recuperer les cartes avalees, recuperer les 
cheques deposes, remplacer le ruban de papier, etc.). 

Systeme d'autorisation (Sys. Auto.) : 

• Neant. 

Systeme d'information (SI) banque : 

• Neant. 

A retenir ACTEUR PRINCIPAL OU SECONDAIRE 

Contrairement a ce que Ton pourrait croire, tous les acteurs n'utilisent 
pas forcement le systeme ! Nous appelons acteur principal celui pour 
qui le cas d'utilisation produit un resultat observable. Par opposition, 
nous qualifions d'acteurs secondaires les autres participants du cas 
d'utilisation. Les acteurs secondaires sont souvent sollicites pour des 
informations complementaires ; ils peuvent uniquement consulter ou 
informer le systeme lors de I'execution du cas d'utilisation. 



3. II n'est pas necessaire de repertorier deux cas d'utilisation distincts appeles Deposer du numeraire et Deposer des cheques. 
En effet, ils auraient le meme acteur principal et le meme objectif global. Cependant, cette decision pourra etre remise 
en cause lors de la description detaillee des cas d'utilisation si Ton s'apercoit alors que les scenarios sont trop differents. 
N'oubliez pas qu'une decision de modelisation ne doit jamais etre irreversible ! 




Point de vue fonctionnel 



Premiere partie 



C'est exactement le cas des deux acteurs « non humains» de notre 
exemple : le Sys. Auto, et le SI banque sont uniquement sollicites par le 
GAB dans le cadre de la realisation de certains cas d'utilisation. Mais ils 
n'ont pas eux-memes de facon propre d'utiliser le GAB, d'objectif a part 
entiere. 



Etape 3 - Realisation de diagrammes de cas d'utilisation 



On obtient sans difficulte un diagramme preliminaire en transcrivant la reponse prece- 
dente sur un schema qui montre les cas d'utilisation (ovales) relies par des associations 
(lignes) a leurs acteurs principaux (icone du « stick man »). 

A retenir CADRE DE DIAGRAMME : TAG ET NOM 

Notez que depuis UML 2.0, un diagramme peut etre inclus dans un 
cadre accueillant tout le contenu graphique. Le cadre a pour intitule 
le nom du diagramme et etablit sa portee. C'est un rectangle avec un 
petit pentagone (appele tag de nom) place dans Tangle superieur 
gauche, qui contient le type du diagramme et son nom. Le cadre n'est 
cependant pas obligatoire lorsque le contexte est clair. La specifica- 
tion UML definit les tags de chaque type de diagramme, mais cela 
n'a pas de caractere obligatoire et chaque outil a fait ses propres 
choix. Celui que nous avons utilise majoritairement pour les 
nouveaux diagrammes UML 2 du livre, Enterprise Architect de la 
societe Sparx Systems 3 , a pris le parti de definir tous les tags avec deux 
lettres : ud, cd, sd, td, ad sm, id, dd Vous les decouvrirez au fur et 
a mesure des chapitres. Dans le diagramme suivant, ud signifie use case 
diagram. 



a. Le lecteur peut visiter le site web suivant http://www.sparxsystems.com.au/ ou il trouvera une version d'evalua- 
tion du produit Enterprise Architect. Nous recommandons egalement 1' introduction a UML 2 disponible sur le 
meme site. 
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Figure 1-7. 

Diagramme de cas d' utilisation 
preliminaire du GAB 



ud UC du GAB 



7" 



Porteur de carte 



GAB 





EXERCICE 1-4. 

Generalisation entre acteurs 



Proposez une autre version, plus sophistiquee, de ce diagramme de cas d'uti- 
lisation preliminaire. 



J" 

O 



on 



Le cas d'utilisation Retirer de F argent a deux acteurs principaux possibles 
(mais exclusifs du point de vue de la simultaneite) . Une autre facon de 
l'exprimer consiste a considerer l'acteur Client de la banque comme une spe- 
cialisation (au sens de la relation d'heritage) de l'acteur plus general Porteur 
de carte, comme nous l'avons deja indique sur la figure 1-6. Un client de la 
banque est en effet un Porteur de carte particulier qui a toutes les prerogatives 
de ce dernier, ainsi que d'autres qui lui sont propres en tant que client. 

UML permet de decrire une relation de generalisation/specialisation entre 
acteurs, comme cela est indique sur le diagramme de cas d'utilisation suivant. 



Point de vue fonctionnel 



Premiere partie 



Figure 1-8. 

Version plus 
sophistiquee 
du diagramme 
de cas d 'utilisation 
preliminaire 



Cependant, dans notre exemple, l'interet de cette relation de generalisation 
n'est pas evident. Elle permet certes de supprimer l'association entre l'acteur 
Client banque et le cas d'utilisation Retirer de V argent, qui est maintenant 
heritee de l'acteur Porteur de carte, mais ajoute en revanche le symbole de 
generalisation entre les deux acteurs... De plus, nous verrons au paragraphe 
suivant que les acteurs secondares sollicites ne sont pas les memes dans le 
cas du Porteur de carte non client et dans celui du client de la banque. 

Nous ne retiendrons done pas cette solution et nous considererons dans la 
suite du chapitre que les denominations Porteur de carte non client et Porteur 
de carte sont synonymes. 

II nous reste maintenant a ajouter les acteurs secondaires pour completer le 
diagramme de cas d'utilisation. Pour cela, UML propose simplement en stan- 
dard de faire apparaitre ces acteurs avec des associations supplementaires 
vers les cas d'utilisation existants. 

A retenir PRECISIONS GRAPHIQUES AU DIAGRAMME DE CAS D'UTILISATION 

Pour notre part, afin d'ameliorer le contenu informatif de ces 
diagrammes, nous recommandons d'adopter les conventions suivantes : 

- par defaut, le role d'un acteur est « principal » ; si ce n'est pas le cas, 
indiquez explicitement que le role est « secondaire » sur l'association, 
du cote de l'acteur ; 

- dans la mesure du possible, disposez les acteurs principaux a gauche 
des cas d'utilisation et les acteurs secondaires a droite. 
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EXERCICE 1-5. 

Acteurs secondaires 



J- 

o 



Completez le diagramme de cas d'utilisation preliminaire en ajoutant les acteurs 
secondaires. Pour simplifier, ne tenez plus compte pour I'instant de I'operateur de 
maintenance. 

on 

Pour tous les cas d'utilisation propres au client de la banque, il faut claire- 
ment faire intervenir comme acteur secondaire SI banque. 

Mais un probleme se pose pour le cas d'utilisation partage Retirer de V argent. 
En effet, si 1' acteur principal est un Porteur de carte non client, il faudra faire 
appel au Sys. Auto, (qui se chargera ensuite de contacter le SI de la banque du 
porteur), alors que, s'il s'agit d'un client de la banque, le GAB contactera 
directement le SI banque. 

Une premiere solution consiste a ajouter une association avec chacun des deux 
acteurs non-humains. Cette modelisation simpliste ne permet pas au lecteur du 
diagramme de comprendre que les acteurs participent au cas d'utilisation Retirer 
de F argent selectivement deux par deux et non pas tous ensemble (figure 1-9). 



Figure 1-9. 

Version simple du 
diagramme de cas 
d'utilisation complete 



ud UC du GAB 



Porteur de carte non 
client 



GAB 




« Actor" 
Sys. Auto. 



«Actor" 
I. Banqui 



Une autre solution consiste a distinguer deux cas d'utilisation pour le retrait 
d'argent : Retirer de V argent et Retirer de V argent avec une carte de la banque. 
Cette modelisation plus precise, mais plus lourde, est plus parlante pour l'expert 
metier. Elle milite d'ailleurs clairement contre l'utilisation de la generalisation 



Point de vue fonctionnel 



Premiere partie 



entre acteurs evoquee precedemment. En effet, la distinction entre les deux cas 
d'utilisation est contradictoire avec la tentative d'heritage par l'acteur Client 
banque du cas unique Retirer de V argent, qui avait ete envisagee plus haut, alors 
que les acteurs secondares n'avaient pas encore ete ajoutes. Nous garderons cette 
seconde solution pour la suite de l'exercice 4 (figure 1-10). 



Figure 1-10. 

Fragment 
de la version 
plus precise 
du diagramme 
de cas 
d'utilisation 
complete 



Porteur de carte 
non client 



Retirer de I'argent 



«actor» 
Sys. Auto. 



Client banque 



Retirer de I'argent avec une carte 
de la banque 



«actor» 
SI banque 



On notera que le SI banque n'est pas un acteur direct du cas d'utilisation Reti- 
rer de V argent, car nous considerons que le Sys. Auto, se charge de le contac- 
ted en dehors de la portee du GAB . 



Etape 4 - Description textuelle des cas d'utilisation 



Exercice 1-6. 

Partie obligatoire du cas d'utilisation 



Decrivez la partie obligatoire du cas d'utilisation Retirer de l'argent (pour 
l'acteur non client de la banque). 



J" 

O 



on 



Sommaire d'identification 

Titre : Retirer de I'argent 

Resume : ce cas d'utilisation permet a un Porteur de carte, qui n'est pas client 
de la banque, de retirer de I'argent, si son credit hebdomadaire le permet. 
Acteurs : Porteur de carte (principal), Systeme d'autorisation (secondaire). 
Date de creation : 02/03/02 Date de mise a jour : 05/05/06 
Version : 5 .0 Responsable : Pascal Roques 



4. II s'agit ici d'un choix de modelisation arbitraire ! Nous ne disons pas que toute autre solution serait mauvaise, mais 
nous expliquons avec des arguments concrets pourquoi nous preferons la notre. 
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Description des scenarios 
Preconditions 

• La caisse du GAB est alimentee (il reste au moins un billet !). 

• Aucune carte ne se trouve deja coincee dans le lecteur. 

• La connexion avec le Systeme d'autorisation est operationnelle. 

Scenario nominal 

1 . Le Porteur de carte 5 introduit sa carte dans le lecteur de cartes du GAB . 

2. Le GAB verifie que la carte introduite est bien une carte bancaire. 

3. Le GAB demande au Porteur de carte de saisir son code d' identification. 

4. Le Porteur de carte saisit son code d'identification. 

5. Le GAB compare le code d'identification avec celui qui est code sur la 
puce de la carte. 

6. Le GAB demande une autorisation au Systeme d'autorisation. 

7. Le Systeme d'autorisation donne son accord et indique le solde hebdomadaire. 

8. Le GAB demande au Porteur de carte de saisir le montant desire du retrait. 

9. Le Porteur de carte saisit le montant desire du retrait. 

10. Le GAB controle le montant demande par rapport au solde hebdomadaire. 

1 1 . Le GAB demande au Porteur de carte s'il veut un ticket. 

12. Le Porteur de carte demande un ticket. 

13. Le GAB rend sa carte au Porteur de carte. 

14. Le Porteur de carte reprend sa carte. 

15. Le GAB delivre les billets et un ticket. 

16. Le Porteur de carte prend les billets et le ticket. 

Une autre presentation interessante 6 consiste a separer les actions des acteurs 
et du systeme en deux colonnes comme suit : 



1 . Le Porteur de carte introduit sa carte 
dans le lecteur de cartes du GAB . 


2. Le GAB verifie que la carte intro- 
duite est bien une carte bancaire. 

3 . Le GAB demande au Porteur de carte 
de saisir son code d'indentification. 


4. Le Porteur de carte saisit son code 
d'identification. 


5. Le GAB compare le code d'identifi- 
cation avec celui qui est code sur la 
puce de la carte. 

6. Le GAB demande une autorisation 
au Systeme d'autorisation. 



5 . Nous preconisons de mettre sy stematiquement une majuscule devant le nom des acteurs pour ameliorer la lisibilite du 
scenario nominal. 

6. Cette presentation a ete recommandee par C. Larman dans la premiere version de Applying UML and Patterns [Larman 97]. 



Point de vue fonctionnel 



Premiere partie 



7. Le Systeme d'autorisation donne 
son accord et indique le solde 
hebdomadaire. 


8. Le GAB demande au Porteur de 
carte de saisir le montant desire du 
retrait. 


9. Le Porteur de carte saisit le montant 
desire du retrait. 


10 . Le GAB controle le montant demande 
par rapport au solde hebdomadaire. 

11. Le GAB demande au Porteur de 
carte s'il veut un ticket. 


12. Le Porteur de carte demande un 
ticket. 


13. Le GAB rend sa carte au Porteur de 
carte . 


14. Le Porteur de carte reprend sa carte. 


15. Le GAB delivre les billets et un ticket. 


16. Le Porteur de carte prend les billets 
et le ticket. 





Enchainements alternatifs 7 

Al : code d 'identification provisoirement errone 
L'enchamement Al demarre au point 5 du scenario nominal. 

6. Le GAB indique au Porteur de carte que le code est errone, pour la 
premiere ou deuxieme fois. 

7. Le GAB enregistre l'echec sur la carte. 
Le scenario nominal reprend au point 3 . 

A2 : montant demande superieur au solde hebdomadaire 
L'enchamement A2 demarre au point 10 du scenario nominal. 

1 1 . Le GAB indique au Porteur de carte que le montant demande est 
superieur au solde hebdomadaire. 

Le scenario nominal reprend au point 8 . 
A3 : ticket refuse 

L'enchamement A3 demarre au point 1 1 du scenario nominal. 

12. Le Porteur de carte refuse le ticket. 

13. Le GAB rend sa carte au Porteur de carte. 

14. Le Porteur de carte reprend sa carte. 

15. Le GAB delivre les billets. 



7. 



Nous distinguons les enchainements alternatifs (Ax) qui reprennent ensuite a une etape du scenario nominal des enchai- 
nements d'erreur (Ey) qui terminent brutalement le cas d'utilisation en echec. L'objectif de l'acteur principal est done 
atteint par les scenarios nominaux et alternatifs mais pas par ceux d'erreur. 
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16. Le Porteur de carte prend les billets. 
Enchainements d'erreur 

El : carte non-valide 

L'enchamement El demarre au point 2 du scenario nominal. 
3. Le GAB indique au Porteur que la carte n'est pas valide (illisible, 
perimee, etc.), la confisque ; le cas d'utilisation se termine en echec. 

E2 : code d' identification definitivement errone 
L'enchamement E2 demarre au point 5 du scenario nominal. 

6. Le GAB indique au Porteur de carte que le code est errone, pour la 
troisieme fois. 

7. Le GAB confisque la carte. 

8. Le Systeme d'autorisation est informe ; le cas d'utilisation se termine en 
echec. 

E3 : retrait non autorise 

L'enchamement E3 demarre au point 6 du scenario nominal. 

7. Le Systeme d'autorisation interdit tout retrait. 

8. Le GAB ejecte la carte ; le cas d'utilisation se termine en echec. 

E4 : carte non reprise 

L'enchamement E4 demarre au point 13 du scenario nominal. 

14. Au bout de 10 secondes, le GAB confisque la carte. 

15. Le Systeme d'autorisation est informe ; le cas d'utilisation se termine en 
echec. 

E5 : billets non pris 

L'enchamement E5 demarre au point 15 du scenario nominal. 

16. Au bout de 10 secondes, le GAB reprend les billets. 

17. Le cas d'utilisation se termine en echec. 

E6 : annulation de la transaction 

L'enchamement E6 peut demarrer entre les points 4 et 12 du scenario 
nominal. 

4 a 12. Le Porteur de carte demande l'annulation de la transaction en cours. 
Le GAB ejecte la carte ; le cas d'utilisation se termine en echec. 

Une autre presentation interessante des enchainements alternatifs et d'erreur 
consiste a utiliser les conventions preconisees par A.Cockburn 8 . Celui-ci 



8. Le lecteur se referera avec profit a l'excellent ouvrage d'Alistair Cockburn : Rediger des cas d'utilisation efficaces, 
Eyrolles,2001 [Cockbum 01]. 
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propose d'indiquer les differentes alternatives par des lettres collees au chif- 
fre du numero de l'etape du scenario nominal concernee. Une version alterna- 
tive de la solution precedente pourrait etre alors : 
2a. Carte illisible ou non valable : 

Le GAB avertit le Porteur et ejecte la carte ; le cas d' utilisation se 

termine en echec. 
2b. Carte perimee : 

Le GAB avertit le Porteur et conflsque la carte ; le cas d'utilisation 

se termine en echec. 
4a. Delai de saisie du code expire : 

Le GAB avertit le porteur et ejecte la carte ; le cas d'utilisation se 

termine en echec. 

4- 12a. 9 Le Porteur annule la transaction : 

Le GAB ejecte la carte ; le cas d'utilisation se termine en echec. 
5a. Code d' identification errone pour la premiere ou deuxieme fois : 
5a 1 . Le GAB enregistre 1' echec sur la carte. 

5a2. Le GAB avertit le Porteur et le scenario nominal reprend a l'etape 3. 
5b. Code d'identification errone pour la troisieme fois : 

Le GAB avertit le Porteur et conflsque la carte ; le cas d'utilisation 

se termine en echec. 
7a. Transaction refusee par le Systeme d'autorisation : 

Le GAB avertit le Porteur et ejecte la carte ; le cas d'utilisation se 

termine en echec. 
7b. Delai de reponse du Systeme d'autorisation expire : 

Le GAB avertit le Porteur et ejecte la carte ; le cas d'utilisation se 

termine en echec. 
9a. Delai de saisie du montant expire : 

Le GAB avertit le Porteur et ejecte la carte ; le cas d'utilisation se 

termine en echec. 
10a. Montant demande superieur au solde hebdomadaire : 

lOal . Le GAB avertit le Porteur et le scenario nominal reprend a l'etape 8. 
10b. Solde hebdomadaire insuffisant : 

Le GAB avertit le Porteur et ejecte la carte ; le cas d'utilisation se 

termine en echec. 
12a. Le Porteur ne demande pas de ticket : 

Le cas d'utilisation continue a l'identique, sauf l'impression du ticket. 



La notation 4-12 signifie : « de l'etape 4 a l'etape 12 ». 
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14a. Delai de retrait de la carte expire : 

14al . Le GAB confisque la carte et annule la transaction ; 
14a2. Le GAB avertit le Systeme d'autorisation et le cas d'utilisation se 
termine en echec. 

16a. Delai de retrait des billets expire : 

Le GAB confisque les billets et annule la transaction ; le cas d'utili- 
sation se termine en echec . 

l-7a. Coupure r&eau avec le Systeme d'autorisation : 

Le GAB avertit le Porteur et ejecte la carte ; le cas d'utilisation se 
termine en echec. 

Postconditions 

La caisse du GAB contient moins de billets qu'au debut du cas d'utilisation 
(le nombre de billets manquants est fonction du montant du retrait) . 

Une transaction de retrait a ete enregistree par le GAB avec toutes les infor- 
mations pertinentes (montant, numero de carte, date, etc.). Les details de la 
transaction doivent etre enregistres aussi bien en cas de succes que d'echec. 



EXERCICE 1-7. 

Paragraphes optionnels du cas d'utilisation 



Completez la description du cas d'utilisation Retirer de l'argent avec les para- 
graphes optionnels. Detaillez les besoins en interface homme-machine. 



O Exigences non fonctionnelles 



Contraintes 


Descriptif 


Temps de 
reponse 


L'interface du GAB doit reagir en l'espace de 2 secondes au 
maximum. Une transaction nominale de retrait doit durer moins 
de 2 minutes. 


Concurrence 


Non applicable (mono-utilisateur) . 


Disponibilite 


Le GAB est accessible 7 jours sur 7, 24 h sur 24 (global 10 ). 

L' absence de papier pour imprimer les tickets ne doit pas empe- 

cher les retraits. 



10. Cette exigence non fonctionnelle n'est pas reellement specifique au cas d'utilisation et devra done se retrouver au final 
dans un document plus global. Elle a uniquement ete citee (ainsi que les suivantes) pour etoffer le paragraphe. 
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Contraintes 


Descriptif 


Integrite 


Les interfaces du GAB doivent etre tres robustes pour prevenir le 
vandalisme. 


Confidentialite 


La comparaison du code d'identification saisi sur le clavier du 
GAB avec celui de la carte doit etre fiable a 10~ 6 . 



Besoins d'lHM 

Les dispositifs d' entree/sortie a la disposition du Porteur de carte doivent etre : 

• Un lecteur de carte bancaire. 

• Un clavier numerique (pour saisir son code), avec des touches 
« validation », « correction » et « annulation ». 

• Un ecran pour 1'affichage des messages du GAB. 

• Des touches autour de 1' ecran pour selectionner un montant de retrait parmi 
ceux qui sont proposes. 

• Un distributeur de billets. 

• Un distributeur de tickets. 

Etape 5 - Description graphique des cas d'utilisation 



Pour documenter les cas d'utilisation, la description textuelle est indispensable, car elle 
seule permet de communiquer facilement avec les utilisateurs et de s'entendre sur la 
terminologie metier employee. 

En revanche, le texte presente des desavantages puisqu'il est difficile de montrer comment 
les enchainements se succedent, ou a quel moment les acteurs secondares sont sollicites. En 
outre, la maintenance des evolutions s'avere souvent fastidieuse. II est done recommande de 
completer la description textuelle par un ou plusieurs diagrammes dynamiques UML. 

A retenir DESCRIPTIONS DYNAMIQUES D'UN CAS D'UTILISATION 

Pour les cas d'utilisation, on peut utiliser le diagramme d'activite car les 
utilisateurs le comprennent d'autant plus facilement qu'il parait ressem- 
bler a un organigramme traditionnel b . 

b. UML 2 propose un nouveau type de diagramme, appele « Interaction Overview Diagram », qui fusionne les 
diagrammes d'activite et de sequence. L'utilisation de ce nouveau diagramme parait prometteuse au niveau des 
cas d'utilisation, voire du systeme global. Nous en donnerons un exemple dans la suite du chapitre. 
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Figure 1-11. 

Bases du diagramme d'activite UML 2 



ucu 



f lot 



Action 1 



Action 2 
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Pour des scenarios particuliers, le diagramme de sequence est une bonne 
solution. 



Figure 1-12. 

Bases du diagramme de sequence UML 2 
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Nous recommandons de le presenter en montrant I'acteur principal a 
gauche, puis un objet unique representant le systeme en boTte noire, et, 
enfin, les eventuels acteurs secondaires sollicites durant le scenario a 
droite du systeme. Nous utiliserons I'intitule diagramme de sequence 
systeme comme cela est propose dans [Larman 97]. 

Avec les interessants ajouts au diagramme de sequence apportes par 
UML 2, en particulier les cadres d'interactions (avec les operateurs 
loop, opt et alt par exemple), ainsi que la possibility de referencer 
une interaction decrite par ailleurs, le diagramme de sequence systeme 
nous semble constituer une excellente solution. 
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EXERCICE 1-8. 

Diagramme de sequence systeme 



Realisez un diagramme de sequence systeme qui decrit le scenario nominal du 
cas d'utilisation Retirer de l'argent. 



o 



on 



II suffit de transcrire sous forme de diagramme de sequence les interactions 
citees dans le scenario textuel de la reponse 1-6, en utilisant les conventions 
graphiques citees plus haut : 

• l'acteur principal Porteur de carte a gauche ; 

• un participant representant le GAB au milieu ; 

• l'acteur secondaire Sys. Auto, a droite du GAB. 



Porteur de carte 



Figure 1-13. 

Diagramme 
de sequence systeme 
du scenario nominal 
de Retirer de l'argent 



introduction carte 



demande code 
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demande montant retrait 



montant retrait (valeur) 
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ejection carte 



recuperation carte 
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Contrairement au diagramme de sequence precedent qui ne decrit que le scenario 
nominal, le diagramme d'activite doit representer l'ensemble des actions realisees par le 
sy steme, avec tous les branchements conditionnels et toutes les boucles possibles. 

C'est un graphe oriente d'actions et de transitions. Les transitions sont franchies lors de 
la fin des actions ; des etapes peuvent etre realisees en parallele ou en sequence. 




EXERCICE 1-9. 

Diagramme d'activite 



Realisez un diagramme d'activite qui decrit la dynamique du cas d'utilisation 
Retirer de l'argent. 



.i: Le diagramme d'activite est decrit sur la figure suivante avec un reperage des 
O principaux symboles graphiques. 

Notez que le diagramme differe legerement du texte : il omet l'etape de demande 
de ticket dans un souci de simplification. Neanmofns, le resultat de cette demande 
est pris en compte par la condition de garde avec le label « ticket demande ». 



Figure 1-14. 

Diagramme 
d'activite de 
Retirer de 
l'argent 



[non-OK pou r la 1 re ou 2e f ois] 



( Verification diA x -X [OK] / Demande \ >-\ 

V code ) ^^^y^ k d'autorisation VisaJ 



[ carte valide ] 



[ carte non valide ] 




Condition 
de garde 
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EXERCICE 1-10. 

Diagramme de sequence systeme enrichi 

A retenir AJOUTS AU DIAGRAMME DE SEQUENCE SYSTEME 

Une possibility interessante consiste a enrichir le diagramme de sequence 
systeme du scenario nominal pourfaire apparaitre egalement : 

- les principales actions internes du systeme (au moyen de messages 
qu'il s'envoie a lui-meme) ; 

- les renvois aux enchamements alternatifs et d'erreur (au moyen de 
notes). 

Cela donne souvent un diagramme moins complexe a lire que ne Test 
un diagramme d'activite, car moins riche en symboles, mais au contenu 
informatif appreciable pour I'expert metier. 



Enrichissez le diagramme de sequence systeme qui decrit le scenario nominal 
du cas d'utilisation Retirer de l'argent. 



o 

Figure 1-15. 

Diagramme de sequence 
systeme enrichi du 
scenario nominal de 
Retirer de l'argent 



Porteur de carte 



introduction carte 



demande code 



verification carte 



verification code 



Voir E3 : 
retrait non 
auto rise 



— _ autorisation (solde) 
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demande montant retrait 



montant retrait (valeur) 



demande ticket 



ejection billets + ticket 



recuperation billets + tickets 



Voir E1 : Li 
carte non valide 



VoirAI et E2 : 
code errone 



demande autorisation 



controledu montant demande 



Voir A2 : 
montant demande 
superieur au solde 
hebdomadaire 



Voir A3 : L\ 

ticket refuse 



Voir E4 : fc*, 
carte non reprise 



Voir E5 : L\ 
billets non prls 
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Etape 6 - Organisation des cas d'utilisation 



Dans cette avant-derniere etape, nous allons affiner nos diagrammes et nos descriptions. 

Avec UML, il est en effet possible de detailler et d'organiser les cas d'utilisation de deux 
facons differentes et complementaires : 

• en ajoutant des relations d'inclusion, d'extension et de generalisation entre cas 
d'utilisation ; 

• en les regroupant en packages, afin de definir des blocs fonctionnels de plus haut 
niveau. 

Abordons tout d'abord la relation d'inclusion : le cas d'utilisation de base en incor- 
pore explicitement un autre, de facon obligatoire, a un endroit specifie dans ses 
enchainements. On utilise cette relation pour eviter de decrire plusieurs fois le 
meme enchainement, en factorisant le comportement commun dans un cas d'utilisa- 
tion a part. 




EXERCICE 1-11. 

Inclusion entre cas d'utilisation 



Identifiez une partie commune aux differents cas d'utilisation et factorisez-la 
dans un nouveau cas inclus dans ces derniers. 

O Si Ton examine en detail la description textuelle du cas d'utilisation Retirer 
O de V argent, on s'apercoit que le debut du scenario nominal va egalement etre 
vf* applicable a tous les cas d'utilisation du client de la banque, en remplacant 
« Porteur de carte » par « Client de la banque » : 

1 . Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB . 

2. Le GAB verifie que la carte introduite est bien une carte bancaire. 

3. Le GAB demande au Porteur de carte de saisir son code d' identification. 

4. Le Porteur de carte saisit son code d' identification. 

5. Le GAB compare le code d' identification avec celui qui est code sur la 
puce de la carte. 

Cet enchainement nominal est en outre complete par les enchainements alter- 
natifs ou d'erreur Al (code d' identification provisoirement errone), El (carte 
non valide) et E2 (code d' identification definitivement errone). 
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On peut done legitimement identifier un nouveau cas d'utilisation 11 inclus 
dans les precedents, que nous appellerons S'authentifier, et qui contient les 
enchainements cites plus haut. Cela nous permettra d'enlever des autres cas 
d'utilisation toutes ces descriptions textuelles redondantes, en se concentrant 
mieux sur leurs specificites fonctionnelles. 

En UML, cette relation d'inclusion obligatoire est formalisee par une fleche 
de dependance entre le cas d'utilisation de base et le cas inclus, nommee avec 
le mot-cle «±nclude», comme cela est indique sur le schema suivant. 



Figure 1-16. 

Relation d'inclusion 
entre cas d'utilisation 




S authentmer ^ 

o' "o 

Retirer de I'argent avec une carte Retirer de I'argent 

de la banque 

L'identification du fragment S' authentlfier permet d'alleger le diagramme de 
sequence systeme en utilisation le cadre ref propose par UML 2. Le debut du 
diagramme remanie est donne sur la figure 1-17. Notez la contrainte temporelle sur la 
reponse du systeme d'autorisation. 



11. Jacobson a propose dans un article recent de parler de fragment plutot que de cas d'utilisation a part entiere, car 
s'authentifier n'est pas un objectif a part entiere de l'utilisateur du GAB ! Pour renforcer ce concept, nous preconisons 
d'utiliser un mot-cle (ou stereotype) « fragment » pour le differencier des autres cas d'utilisation. 
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Nouveau 

diagramme 

de sequence 

systeme 

avec reference 

au cas incius 
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sd Retirer de I'argent (nominal) 



:Client banque 



« systems 
:GAB 



:Sys. Auto. 



S'authentifier (nominal) 



demande autorisation(numCarte) 



autorisation(solde) 



{< 2s) 



demande montant retrait 



Le cadre ref fait reference a un autre diagramme de sequence donne figure 1-18. 



Figure 1-18. 

Diagramme 

de sequence systeme 

du fragment ref erence 



sd S'authentifier (nominal) 



Client banque 



introduction carte 



demande code 



saisie code(valeur) 



code OK 



« systems 
GAB 



' verification carte 



; verification code 



Poursuivons notre analyse par la relation d 'extension : cette fois-ci, le cas de base en 
incorpore implicitement un autre, mais de fagon optionnelle, a un endroit specifie indi- 
rectement dans celui qui precede a l'extension. On utilise cette relation pour separer un 
comportement optionnel ou rare du comportement obligatoire. 
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EXERCICE 1-12. 

Extension entre cas d'utilisation 

En extrapolant sur les besoins initiaux, identifiez une relation d'extension 
entre deux cas d'utilisation du client de la banque. 



O 



on 



En reexaminant la question du retrait d'argent, on a tot fait de s'apercevoir que 
le client de la banque applique quasiment le meme enchainement nominal que 
le Porteur de carte. Mais, en tant que client, il a egalement acces aux autres cas 
d'utilisation : pourquoi ne pas lui permettre de consulter son solde juste avant 
qu'il ne choisisse le montant de son retrait ? II pourrait ainsi ajuster le montant 
demande avec ce qu'il lui reste a ce moment sur son compte. 

Si Ton retient ce nouveau besoin fonctionnel, pour le modeliser en UML il 
suffit d'ajouter une relation d'extension optionnelle comme cela est indique 
sur la figure suivante. 



Figure 1-19. 

Relation d'extension entre 
cas d'utilisation 



Point 
d' extension 

J 



Condition : {porteur choisit 

Consultation solde} 

Extension point : verification montant 



Points d'extension 

Verification montant, etc 



«extend» / 



Retirer de I'argent avec une carte 
de la banque 



Consulter le solde 



Relation 
d' extension 



Les deux cas d'utilisation peuvent bien sur s'executer independamment, mais 
Consulter le solde peut egalement venir s'intercaler a l'interieur de Retirer de 
V argent avec une carte de la banque, au point d'extension Verification mon- 
tant. Ce point d'extension doit etre declare dans la description textuelle, par 
exemple en modifiant comme ceci 1' enchainement nominal : 



7. Le SI banque donne son accord et indique le solde hebdomadaire. 

8 . Le GAB demande au Client banque de saisir le montant desire du retrait. 
Point d' 'extension : Verification montant 

9. Le Client banque saisit le montant desire du retrait. 

10. Le GAB controle le montant demande par rapport au solde hebdomadaire. 



Poursuivons enfm par la relation de generalisation I specialisation : les cas d'utili- 
sation descendants heritent de la description de leur parent commun. lis peuvent 
neanmoins comprendre chacune des interactions specifiques supplementaires, ou 
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modifier les interactions dont ils ont herites. On utilise cette relation pour formaliser 
des variations importantes 12 sur le meme cas d'utilisation. 



Identifiez une relation de generalisation / specialisation qui implique un cas 
d'utilisation du client de la banque. 



O Considerons le cas d'utilisation Deposer de V argent. II possede deux scena- 
rios principaux : Deposer du numeraire et Deposer des cheques. Reprenons 
la discussion entamee en debut de chapitre : est-il souhaitable de distinguer 
ces scenarios en tant que cas d'utilisation a part entiere ? Essayons de trouver 
les arguments pour et contre. 

Ils mettent en jeu les memes acteurs : le Client banque comme acteur princi- 
pal et le SI banque comme acteur secondaire. Mais surtout, ils parlent de la 
meme chose : la possibilite offerte a un client de la banque d'effectuer un 
depot d'argent grace au GAB. Le fait que cette transaction consiste a glisser 
des billets dans un lecteur de billets, ou a simplement deposer une enveloppe 
contenant un ou plusieurs cheques, n'est pas fondamental. Le resultat sera 
similaire, a savoir une ligne de credit sur le compte du client. 

Pourtant, le detail des enchainements va varier notablement : le depot de 
numeraire implique par exemple un dispositif de reconnaissance de billets, 
avec des interactions liees a chaque introduction de billets, aux erreurs 
possibles (billet non reconnu, etc.) et a la fin de la transaction. II est aussi 
probable que le systeme de tenue des comptes (qui fait partie du SI banque) 
soit informe en temps reel du depot afin de crediter le compte, alors que le 
depot de cheques donnera lieu pour sa part a une verification manuelle par un 
guichetier bien apres que la transaction fut terminee. En distinguant deux cas 
d'utilisation, nous ajoutons la possibilite de leur associer des acteurs secon- 
dares differents. 

Pour formaliser cette unite fonctionnelle, tout en se gardant la possibilite de 
decrire les differences au niveau des enchainements, nous pouvons utiliser la 




EXERCICE 1-13. 

Generalisation / specialisation entre cas d'utilisation 



12. Nous insistons sur le mot « important », car cette relation de generalisation entre cas d'utilisation se revele souvent inu- 
tile dans la pratique, voire dangereuse. Elle ajoute de la complexity au diagramme, ce qui peut rebuter l'expert metier 
qui doit le valider, surtout si le modelisateur utilise egalement l'inclusion et 1' extension ! 
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relation de generalisation / specialisation. II suffit de considerer que Deposer 
de I 'argent est un cas d'utilisation generalise. Ce cas a maintenant la particu- 
larite d'etre abstrait (il apparait alors en italiques), car il ne s'instancie pas 
directement, mais uniquement par le biais de l'un de ses deux cas specialises. 



Figure 1-20. 

Relation de generalisation 
entre cas d'utilisation 




Deposer des Deposer du 

cheques numeraire 



Le diagramme des cas d'utilisation du client banque fait apparaitre egalement 
la factorisation rendue possible de la relation d'inclusion avec le fragment de 
cas d'utilisation S'authentifier. II permet surtout d'associer l'acteur secondaire 
SI. Banque avec le seul cas d'utilisation specialise Deposer du numeraire. 




Figure 1-21. 

Cas d'utilisation du client banque 
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Avec tous ces ajouts, que devient done notre diagramme de cas d'utilisation ? II 
est maintenant si complexe (compare a la figure 1-7) qu'il serait illusoire de pen- 
ser qu'il puisse etre lisible en une seule page, comme le montre le schema suivant. 

Notez que nous avons introduit un acteur generalise abstrait « Porteur » en 
tant qu'acteur principal du fragment de cas d'utilisation s'authentifier. Cela 
nous permet ainsi d'inclure ce fragment dans les cas d'utilisation du client 
mais aussi du porteur non client. 

Notez egalement que nous avons distingue les cas d'utilisation de l'operateur 
de maintenance par le mot-cle « support », pour mettre l'accent sur la diffe- 
rence de niveau avec les cas principaux que sont ceux des porteurs de carte. lis 
sont en general moins importants fonctionnellement, mais ne doivent cependant 
pas etre oublies. Imaginez un GAB que Ton ne pourrait pas recharger en billet ! 



Figure 1-22. 

Diagramme de cas d'utilisation 
complet du GAB 
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Pour ameliorer notre modele, nous allons done organiser les cas d'utilisation et les 
regrouper en ensembles coherents. Pour ce faire, nous utilisons le mecanisme general de 
regroupement d'elements en UML, qui s'appelle le package. Le package est une sorte 
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de dossier permettant de structurer un modele en unites coherentes. Les outils de mode- 
lisation du marche se servent pour la plupart de ce concept comme unite de gestion de 
version, de stockage, et de partage du modele pour le travail en equipe. Nous y revien- 
drons plus en detail dans la partie II (modelisation statique). 



EXERCICE 1-14. 

Structuration des cas d'utilisation en packages 

Proposez une structuration des cas d'utilisation du GAB en packages. 



O Plusieurs strategies sont possibles : proceder au regroupement par acteur, par 
O domaine fonctionnel, etc. Dans notre exemple, un regroupement des cas 
vP* d'utilisation par acteur principal s'impose, car cela permet egalement de 
repartir les acteurs secondaires. 

Le cas d'utilisation inclus S' authentifier est mis dans un package a part, en tant 
que fragment commun, pour bien le distinguer des vrais cas fonctionnels qui 
l'incluent. Les Heches de dependance entre packages de cas d'utilisation syn- 
thetisent les eventuelles relations entre les cas, c'est-a-dire ici les inclusions. Le 
schema suivant presente la structuration proposee des cas d'utilisation. II s'agit 
d'un diagramme de packages, officialise par UML 2. 



Figure 1-23. 

Diagramme de packages des cas 
d'utilisation du GAB 




II est maintenant possible de dessiner un diagramme de cas d'utilisation par 
packages. Cela ne presente aucune difficulte et nous donnerons uniquement le 
diagramme du premier package, pour montrer comment apparait le fragment 
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appartenant a un package different. La notation (from Fragments) n'est pas 
standard UML, mais est utilisee par plusieurs outils du marche. 



Figure 1-24. 

Diagramme de cas 
a" utilisation du 
package Operations 
non client 



ud Porteur de carte 



Porteur de carte non 
client 



V 




« a cto r» 
Sys. Auto. 



(from Fragments) 



Etape 7 - Dynamique globale : Interaction Overview Diagram 



Dans cette derniere etape, nous allons explorer l'utilisation d'un nouveau type de 
diagramme UML 2 : Interaction Overview Diagram^. 

Ce diagramme est une fusion interessante du diagramme d'activite et du diagramme de 
sequence ! II permet d'organiser des interactions, representees par exemple par des 
diagrammes de sequence, au moyen des nceuds de controle du diagramme d'activite : 
decision, parallelisme, etc. C'est done une sorte de diagramme d'activite 14 dans lequel 
les actions sont remplacees par des interactions. 




EXERCICE 1-15. 

Interaction Overview Diagram 



Representez la dynamique globale du GAB dans le point de vue de I'acteur 
Client banque, en representant les interactions de ses cas d'utilisation 
dans un Interaction Overview Diagram. Modelisez en particulier le fait que le 
client peut enchamer plusieurs transactions (retrait, depot, etc.) sans avoir a 
s'authentifier de nouveau. 



13. Nous preferons conserver le nom d'origine des nouveaux types de diagrammes UML 2 en attendant qu'une traduction 
francaise s'impose (diagramme de vue globale d'interaction ? diagramme de vue d'ensemble des interactions ? etc.). 

14. Pourtant, l'outil utilise le tag sd, car dans les specifications UML 2.0, ce diagramme est classe dans la categorie des dia- 
grammes d'interaction, et ceux-ci (sequence, communication, timing, interaction overview) sont tous representes avec 
un tag sd. 



Point de vue fonctionnel 



Premiere partie 



on 



^ Representons d'abord le processus d'authentification, suivi du choix du type 
~q de transaction : retrait, consultation ou depot.. Le diagramme global est des- 
vT* sine sur la figure 1-25. 



Figure 1-25. 

Vue d' ensemble 
des interactions 
du client banque 



sd Dynamique globale client (references) 



Retirer de I'argent 



1 



ref 



S'authentifier 



[NOT OK] 

^ ^K*) 

Echec 



[OK] 



Type de transaction 




[Consul 

\ 


ation] 


refj 

Consulter son solde 







Deposer de I'argent 



II est egalement possible de remplacer chaque reference par un diagramme de sequence 
« inline ». Nous l'avons fait pour l'interaction S ' authentlfier. II est clair que le 
souci de lisibilite du diagramme empeche de remplacer chaque reference par un 
diagramme de sequence entier. 



Modelisation fonctionnelle : etude de cas 



Chapitre 1 



sd Dynamique globale client 



sntifier (nominal) ^ 



:Porteur de carte 



« syste m » 
:GAB 



introduction carte 



demande code 



saisie code(valeur) 



verification carte 



verification code 



[NOT OK] 



[OK] 



Type de transaction 



[Re rait] 

V 



[Consu 



ref 



Retirer de I'argent 




ref 



Consulter son solde 



[De jot] 
V 



ref 



Deposer de I'argent 



V 



A 

Termine ? 



[Non] 



[Oui] 



® 



Figure 1-26. 

Vue d 'ensemble des interactions du client banque (expanse) 



Chapitre Modelisation fonctionnelle : 

2exercices corriges et 
conseils methodologiques 



.\es 



4-1 

o 



m Diagramme de cas d'utilisation a Relations entre cas 
d'utilisation ■ Navigabilite des associations entre 
acteurs et cas d'utilisation ■ Description textuelle d'un 
cas d'utilisation ■ Diagramme de sequence systeme 
■ Fragment d'interaction, operateur ■ Diagramme d'etats 
des operations systeme. 



Une nouvelle etude de cas va nous permettre dans ce chapitre 
de completer le passage en revue des principales difficultes rela- 
tives a la mise en ceuvre de la technique des cas d'utilisation. 

Nous allons elaborer un diagramme de cas d'utilisation com- 
plexe incluant les differents types de relations entre cas 
d'utilisation ainsi qu'une notation avancee : la fleche de 
navigabilite sur les associations entre acteurs et cas d'utili- 
sation. Nous introduirons ensuite la difference entre cas 
d'utilisation essentiel et cas d'utilisation reel, initialement 
proposee par [Larman 97], et observerons comment el le 
influence la description textuelle. Nous utiliserons les nou- 
veautes les plus interessantes du diagramme de sequence, 
comme les fragments d'interaction, avec les operateurs les 
plus utiles. Enfin, nous donnerons un exemple de diagramme 
d'etats montrant la sequence forcee des operations systeme 
lors d'un cas d'utilisation particulier. 



Point de vue fonctionnel 

Premiere partie 

Etude d'un terminal point de vente (tpv) 




Cet exercice concerne un systeme simplifie de caisse enregistreuse de supermarche. 
II est largement inspire de l'etude de cas initialement proposee par [Larman 97] et 
qui forme la base de la formation OOAD 1 de Valtech Training. 

Le deroulement normal d'utilisation de la caisse est le suivant : 

• Un client arrive a la caisse avec des articles a payer. 

• Le caissier enregistre le numero d' identification (CPU) de chaque article, ainsi 
que la quantite si elle est superieure a un. 

• La caisse affiche le prix de chaque article et son liberie. 

• Lorsque tous les achats sont enregistres, le caissier signale la fin de la vente. 

• La caisse affiche le total des achats. 

• Le client choisit son mode de paiement : 

- numeraire : le caissier encaisse 1' argent recu, la caisse indique la monnaie a 
rendre au client ; 

- cheque : le caissier verifie la solvability du client en transmettant une requete a 
un centre d'autorisation via la caisse ; 

- carte de credit : un terminal bancaire fait partie de la caisse. II transmet une 
demande d'autorisation a un centre d'autorisation en fonction du type de la 
carte. 

• La caisse enregistre la vente et imprime un ticket. 

• Le caissier donne le ticket de caisse au client. 

Apres la saisie des articles, le client peut presenter au caissier des coupons de reduction 
pour certains articles. Lorsque le paiement est termine, la caisse transmet les informa- 
tions sur le nombre d'articles vendus au systeme de gestion de stocks. 

Tous les matins, le responsable du magasin initialise les caisses pour la journee. 



1 . OOAD = Object Oriented Analyis & Design. 
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Etape 1 - Realisation du diagramme de cas d'utilisation 
Exercice 2-1. 

Diagramme de cas d'utilisation 

Elaborez un diagramme de cas d'utilisation detaille de la caisse enregistreuse. 

N'hesitez pas a utiliser les relations entre cas d'utilisation pour rendre votre 
diagramme plus precis. 



5> 



on 



Dans un premier temps, une solution simpliste consiste a identifier un 
O « g ros » cas d'utilisation qui contient la totalite du deroulement normal d'uti- 
lisation de la caisse et un autre cas d'utilisation qui traite de 1' initialisation de 
la caisse par le responsable du magasin. 

Figure 2-1. 

Premiere ebauche du diagramme de cas 
d'utilisation 



Caissier 



Traiter le passage en caisse 



Responsable 
magasin 



Initialiser la caisse 



Si Ton ajoute les acteurs secondaires sur le schema precedent, on s'apercoit 
que le cas d'utilisation Traiter le passage en caisse communique avec un 
grand nombre d' acteurs differents. 



Figure 2-2. 

Deuxieme ebauche du 
diagramme de cas d'utilisation 



Caissier 



Traiter le passage en caisse 



secondaire 



«actor» 
Centre autorisation cheques 




?<actor» 
Gestion des stocks 



Navigabi lite 



Responsable 
magasin 



Initialiser la caisse 



Point de vue fonctionnel 



Premiere partie 



A retenir ACTEUR RECEPTEUR UNIQUEMENT 

Notez I'utilisation de la fleche de navigabilite sur I'association avec 
I'acteur non-humain Gestion des stocks qui permet de preciser que 
I'acteur ne fait que recevoir des messages du systeme, sans jamais lui en 
envoyer. 



Cette proliferation d'acteurs secondaires nous amene a diagnostiquer que ce 
cas d'utilisation a trop de responsabilites, et qu'il est souhaitable de le decou- 
per en parties plus atomiques. On pourrait penser qu'il suffit de le scinder 
sequentiellement comme cela est illustre sur la figure 2-3 . 



Figure 2-3. 

Decoupe 

sequentielle du cas 

d'utilisation 

principal 



Enregistrer les articles^ 




secondaire 



Caissier 



Terminer la vente 



secondaire, 

econdaire Client 



Traiter le paiement ■ 



secondaire 



«actor» 
Centre autorisation cheques 



secondaire 



secondaire 



«actor» 
Centre autorisation cartes 



V 



«actor» 
Gestion des stocks 



Quoique tentante, cette solution est rarement recommandable. En effet, les 
cas d'utilisation qui en resultent ne repondent plus vraiment a la definition 
UML. Peut-on par exemple considerer que Terminer la vente represente un 
service de bout en bout qui est rendu par le systeme ? 
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Le niveau de detail ainsi obtenu s'apparente plutot a ce que Larman appelle 
des operations systeme 2 , soit a une unite de traitement qui est realisee par le 
systeme dans le cadre d'un cas d'utilisation et qui peut eventuellement etre 
reutilisee dans un autre. 

L'enregistrement des articles et la cloture de la vente font intervenir les 
memes acteurs et se suivent forcement dans le temps : il n'y a done pas de 
raison de les separer. En revanche, l'importante partie variable, qui est liee 
au choix du mode de paiement par le client, conduit a separer, grace a une 
relation d'inclusion, la procedure generique de paiement du processus englo- 
bant de traitement du passage en caisse. Cela permet ainsi de decrire des cas 
d'utilisation specialises, faisant chacun apparaitre des acteurs specifiques. 
Le debut de l'enonce peut done se modeliser comme cela est represente sur 
la figure suivante. 



Figure 2-4. 

Diagramme de cas 
d'utilisation partiel 




C3 



secondaire 




Caissier 



Traiter le passage en caisse 



Client 



«include» 



Cas 

d'utilisation 
abstrait 




Traiter le paiement 




A 




Traiter le paiement en liquide 



Traiter le paiement par carte de credit 




Traiter le paiement par cheque 





«actor» 
Centre autorisation cartes 



2. 



Par analogie avec les operations que sont capables de realiser les objets, suite a la reception de messages venant d'un 
autre objet. A ce niveau, le systeme boite noire est vu comme un « gros » objet, et les acteurs lui envoient des messages 
qui declenchent des operations « systeme ». 



Point de vue fonctionnel 



Premiere partie 



Le cas d'utilisation inclus, Traiter le paiement, est porte en italique sur le dia- 
gramme pour indiquer qu'il s'agit d'un cas d'utilisation abstrait (non instan- 
ciable). Pour ne pas surcharger le schema, nous n'avons pas reporte les 
associations avec Caissier et Client sur Traiter le paiement. On notera cepen- 
dant que deux cas d'utilisation specialises possedent une association specifique 
avec un acteur supplementaire : le centre d'autorisation les concernant. 

Nous pouvons maintenant completer le modele en integrant la fin de l'enonce. 

La prise en compte optionnelle des bons de reduction se traduit assez naturelle- 
ment par une relation d'extension avec le cas d'utilisation principal. La liaison 
avec le systeme externe de gestion des stocks donne lieu a une association uni- 
directionnelle avec un nouvel acteur. L'initialisation de la caisse ne presente pas 
de difficulte. Le diagramme de cas d'utilisation complete est presente ci-apres. 



Figure 2-5. 

Diagramme 
de cas 



d'utilisation Responsable 



Point 
d ' extension 



complete 



magasin 



Condition : le client presente des coupons 
Point d'extension : coupons 



Prendre en compte les coupons 
de reduction 
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Etape 2 - Descriptions essentielle et reel le d'un cas d'utilisation 



x 



EXERCICE 2-2. 

Description essentielle d'un cas d'utilisation 

A retenir CAS D'UTILISATION ESSENTI EL/REEL 

C. Larman a introduit dans [Larman 97] la distinction entre cas d'utilisa- 
tion essentiel et cas d'utilisation reel : 

- Essentiel : decrit un processus, d'un point de vue analytique. Explicite 
un processus le plus independamment possible de I'environnement 
materiel/logiciel. 

- Reel : decrit un processus, du point de vue de la conception. Explicite 
une solution en termes d'evenements, d'interface utilisateur, d'entrees 
de donnees, etc. 

Nous allons illustrer cette difference avec les deux questions suivantes. 

Ecrivez une description detaillee essentielle du cas d'utilisation principal : 
Traiter le passage en caisse. 



O Sommaire d'identification 

O Titre : Traiter le passage en caisse Type : essentiel detaille 

Resume : un client arrive a une caisse avec des articles qu'il souhaite acheter. 
Le caissier enregistre les achats et recupere le paiement. A la fin de l'opera- 
tion, le client part avec les articles. 

Acteurs : Caissier (principal), Client (secondaire) . 

Date de creation : 17/10/03 Date de mise a jour : 11/05/06 

Version : 1 .5 Responsable : Pascal Roques 

Description des scenarios 
Preconditions 

Le TPV est en service ; un caissier y est connecte ; 
Le catalogue produit est disponible. 



Point de vue fonctionnel 



Premiere partie 



Scenario nominal 



1. Ce cas d'utilisation commence quand 
un client arrive a la caisse avec des 
articles qu'il souhaite acheter. 




2. Le Caissier enregistre chaque article. 
S'il y a plus d'un exemplaire par arti- 
cle, le Caissier indique egalement la 
quantite. 


3. Le TPV valide le CPU et determine 
le prix de 1' article. 

Le TPV affiche la description et le 
prix de Particle en question. 


4. Apres avoir enregistre tous les arti- 
cles, le Caissier indique que la vente 
est terminee. 


5 . Le TPV calcule et affiche le montant 
total de la vente. 


6. Le Caissier annonce le montant total 
au client. 




7 . Le Client choisit le type de paiement : 

a. En cas de paiement cash, executer le 
cas d'utilisation « Traiter le paiement 
en liquide » . 

b. En cas de paiement par carte de credit, 
executer le cas d'utilisation « Traiter 
le paiement par carte de credit ». 

c. En cas de paiement par cheque, exe- 
cuter le cas d'utilisation « Traiter le 
paiement par cheque » . 






8. Le TPV enregistre la vente effectuee 
et imprime un ticket. 


9. Le Caissier donne le ticket de caisse 
au Client. 




10. Le Client s'en va avec les articles qu'il 
a achetes. 





Enchainements alternatifs 

Al : numero d' identification inconnu 

L'enchamement Al demarre au point 3 du scenario nominal. 
3. Le TPV indique au Caissier que le numero d' identification de Particle est 
inconnu. L' article ne peut alors etre pris en compte dans la vente en cours. 

Le scenario nominal reprend au point 2 s'il y a d'autres articles ou au point 4 
s'il n'y en a pas. 

A2 : demande d'annulation d 'article 

L'enchamement A2 demarre au point 2 du scenario nominal. 

2. Le Caissier demande l'annulation du dernier article (prix errone, etc.). 

3. Le TPV enleve Particle de la vente en cours. 
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Le scenario nominal reprend au point 2 s'il y a d'autres articles ou au point 4 
s'il n'y en a pas. 

Enchainements d'erreur 

El : annulation de la vente 

L'enchamement El peut demarrer du point 2 au point 7 du scenario nominal. 

2.7 Le Caissier annule l'ensemble de la vente et le cas d'utilisation se termine 
en echec. 

Postconditions 

• La vente est enregistree dans le TPV. 

II faudrait egalement decrire chacun des cas d'utilisation specialises. 
Nous ne corrigeons que le premier : 

Sommaire d'identification 

Titre : Traiter le paiement en liquide 

Resume : un client paie en liquide le total affiche par la caisse enregistreuse. 
Acteurs : Caissier (principal), Client (secondaire) . 
Date de creation : 17/10/03 Date de mise a jour : 1 1/05/06 

Version : 1 .5 Responsable : Pascal Roques 

Description des scenarios 
Preconditions 

La saisie des articles de la vente en cours est cloturee. 
Scenario nominal 



1 . Ce cas d'utilisation commence quand 
un Client choisit de payer en especes, 
apres avoir ete informe du montant 
total de la vente. 




2. Le Client donne en paiement une 
somme en especes ; elle est eventuel- 
lement plus elevee que le montant 
total de la vente. 




3 . Le Caissier enregistre la somme don- 
nee par le client. 


4. Le TPV affiche la somme qui doit 
etre rendue au Client. 


5. Le Caissier encaisse l'argent recu et 
sort la monnaie qu'il doit rendre. 




6. Le Caissier rend la monnaie au Client. 





Point de vue fonctionnel 



Premiere partie 



Enchainements alternatifs ou d'erreur 

Al : somme donnee par le client inferieure au montant total de la vente 

L'enchamement Al demarre au point 4 du scenario nominal. 

2. Le TPV signale que la somme donnee par le Client est inferieure au mon- 
tant total de la vente et invite le Caissier a recommencer. 

Le scenario nominal reprend au point 3 . 
El : client ne pouvant payer 

L'enchamement El demarre au point 2 du scenario nominal. 

2. Le client n'a pas assez de liquide pour payer. 

3. Le caissier annule l'ensemble de la vente et le cas d'utilisation se termine 
en echec, ou le client paie avec un autre moyen de paiement (Voir « Traiter 
le paiement par cheque », ou « Traiter le paiement par carte de credit »). 

E2 : caissier ne pouvant rendre la monnaie 

L'enchamement E2 demarre au point 5 du scenario nominal. 

5. Le tiroir du TPV ne contient pas assez d'especes pour qu'il soit possible 
de rendre la monnaie. 

6. Le caissier demande des especes supplementaires a son superieur ou pro- 
pose une autre methode de paiement au client (Voir « Traiter le paiement 
par cheque », ou « Traiter le paiement par carte de credit »). Si aucune 
solution n'est envisageable, le caissier annule l'ensemble de la vente et le 
cas d'utilisation se termine en echec. 



EXERCICE 2-3. 

Description reelle d'un cas d'utilisation 

Ecrivez une description detaillee reelle du cas d'utilisation principal : Traiter 

LE PASSAGE EN CAISSE. 

Proposez tout d'abord une fenetre graphique simple pour I'interface homme- 
machine du caissier. 

s 

q Le sommaire d' identification est similaire au precedent, mais le type devient : 
reel detaille. 



Modelisation fonctionnelle : exercices corriges et conseils methodologiques 



Chapitre 2 



61 



L' interface homme-machine 
proposee est la suivante : 



Caisse enregistreuse 




Quantite 1 



A rendre 



La description du scenario 
nominal devient alors : 



Saisie article | Fin de vente | Saisie paiementj 



paiementj 



1 . Ce cas d'utilisation commence quand 
un Client arrive a la caisse avec des 
articles qu'il souhaite acheter. 




2. Le Caissier enregistre le code univer- 
sel d'identification du produit dans le 
champ « Numero » de la fenetre de 
dialogue de la caisse enregistreuse. 
S'il y a plus d'un exemplaire de 
l'article en question, le Caissier peut 
entrer la quantite dans le champ 
« Quantite », qui est positionne a 
« 1 » par defaut. 

Puis il appuie sur le bouton de 
validation : « Saisie article ». 


3. Le TPV determine le prix de l'arti- 
cle et ajoute les informations sur 
l'article a la vente en cours. 
Le TPV affiche la description (sur 
6 lettres) et le prix de l'article en 
question dans le champ « Total ». 


4. Apres avoir enregistre tous les arti- 
cles, le Caissier appuie sur le bouton 
« Fin de vente » . 


5 . Le TPV calcule et affiche le montant 
total de la vente dans le champ 
« Total ». 


6. Le Caissier annonce le montant total 
au Client. 




7. Le Client choisit le type de paiement : 

• En cas de paiement cash, executer le 
cas d'utilisation « Traiter le paie- 
ment en liquide » . 

• En cas de paiement par carte de cre- 
dit, executer le cas d'utilisation 
« Traiter le paiement par carte de 
credit » . 

• En cas de paiement par cheque, exe- 
cuter le cas d'utilisation « Traiter le 
paiement par cheque » . 





Point de vue fonctionnel 



Premiere partie 





8. Le TPV enregistre la vente qui vient 
d'etre effectuee et imprime un ticket. 


9. Le Caissier donne le ticket de caisse 
au Client. 




10. Le Client s'en va avec les articles 
qu'il a achetes. 





Pour completer, nous donnons ci-apres la version reelle de Traiter le paie- 
ment en liquide. 

Scenario nominal 



1. Ce cas d'utilisation commence 
quand un Client choisit de payer en 
especes, apres avoir ete informe du 
montant total de la vente. 




2. Le Client donne en paiement une 
somme en especes ; elle est eventuel- 
lement plus elevee que le montant 
total de la vente. 




3 . Le Caissier enregistre la somme don- 
nee par le client dans le champ 
« Paiement » . 

11 valide au moyen du bouton 
« Saisie paiement ». 


4. Le TPV affiche la somme qui doit 
etre rendue au Client dans le champ 
« A rendre » . 


5. Le Caissier encaisse l'argent recu et 
sort la monnaie qu'il doit rendre. 




6. Le Caissier rend la monnaie au client. 





t 

Etape 3 - Description graphique des cas d'utilisation 



Exercice 2-4. 

Diagramme de sequence systeme 

Realisez un diagramme de sequence systeme qui decrive le scenario nominal 
du cas d'utilisation essentiel Traiter le passage en caisse, en ne considerant 
que le paiement cash. 
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Aon 

^ II suffit de transcrire sous forme de diagramme de sequence les interactions 
"q citees dans le scenario textuel de la reponse 2-2, en utilisant les conventions 
^pv graphiques adoptees precedemment : 

• l'acteur principal Caissier a gauche ; 

• un participant representant le TPV au milieu ; 

• l'acteur secondaire Client a droite de la Caisse. 

Notez egalement l'utilisation du fragment d'interaction proposee par UML 2, 
avec l'operateur de boucle loop. 



Figure 2-6. 

Diagramme de sequence 
systeme du scenario 
nominal de Traiter le 
passage en caisse 



Caissier 



Caisse 



Client 



loop j J [Pour chaque article] 






! saisie Article (numero, quantite) 






I > 






prix & description 

k 


prix & description 
> 











fin De Ventef 



total 



liquide (montant) 



saisie Paiement (montant) 



a rend re 



ticket 



total 



total a payer 



ticket 



Deux commentaires sur le diagramme precedent : 

• Nous avons choisi de montrer les messages echanges par les acteurs. Cela n'est 
pas strictement necessaire, puisqu'en dehors du perimetre du systeme, mais 
peut neanmoins etre utile au lecteur afm de valider le diagramme. Nous avons 



Point de vue fonctionnel 



Premiere partie 



effectivement plus represente un processus metier qu'un strict cas d' utilisation, 
mais cela est souvent apprecie par l'expert metier. Comparez avec la figure sui- 
vante qui se concentre vraiment sur les interactions avec le systeme. 
• Comme le prix et la description sont envoyes simultanement aux deux 
acteurs, nous avons simplement dessine deux fleches partant du meme 
niveau vertical. Cela nous a paru plus clair pour le lecteur que l'utilisation 
d'un autre operateur UML 2, a savoir « seq » (weak sequencing). 

Si Ton considere que l'ajout de l'acteur Client sur la figure precedente 
n'apporte pas de reelle plus-value, on peut simplifier le diagramme de 
sequence en enlevant sa ligne de vie. 

Par contre, si Ton utilise un formalisme un peu plus sophistique, avec le cadre 
de diagramme, les fleches de retour pointillees, les messages a soi-meme pour 
les traitements du systeme, et la description des pre- et post-conditions grace 
au symbole d'etat sur la ligne de vie, on obtient finalement le diagramme 
suivant : 



Figure 2-7. 

Version plus elaboree du DSS 

du scenario nominal 

de Traiter le passage en caisse 



sd Traiter le passage en caisse (nominal cash) 



«system» 
TPV 



{Caissier authentifie et 
catalogue disponible} 



loop y \ 

[pour cha'que article] 



entrerArticle(cpu,quantite = 1 ) 



, verifierArticle(cpi ) 



prix & description 



terminerSaisieO 



K 



saisirMontantPaye(montant) 



rx 

{montant >- total} | 



; enregistrerVente 



K 



{Nouvelle vente 
enregistree} 



On peut maintenant essayer de completer le diagramme en indiquant les sce- 
narios alternatifs et d'erreur grace a des notes (voir figure 2-8). 
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sd DSS avec alternatives 



:Caissier 



« syste m » 
:TPV 



{caissier authentifie et 
catalogue dlsponlble} 



annulation annulation 



vente 



loop 



[pour chaquie article] saisirArticle(cpu,q) 



dernier 
article 





description & prix 





I - 




cloture rVente() 






total 


► 


:<--- 


saisirMontantPaye(montant) 






verifierProduit(cpu 



reference inconnue 



calculerTotal() 



calculerARendre() 



aRendre 



recu 



~~ ^ 

jntant paye < total | 



enregistrerVente() 



{Nouvelle vente 
enregistree} 



Figure 2-8. 

DSS de Traiter le passage en caisse avec alternatives et erreurs 




EXERCICE 2-5. 

Diagramme de sequence systeme (suite) 



Modifiez le diagramme de sequence precedent afin de prendre en compte les 
differents types de paiement. Proposez egalement un diagramme supplemen- 
taire montrant le travail du caissier pendant les heures d'ouverture du magasin. 

O Pour prendre en compte les differents types de paiement, on peut remplacer le 
O message saisieMontantPaye(montant) du diagramme precedent par une reference 
vers une interaction concernant le cas d'utilisation inclus Traiter le paiement. 



Point de vue fonctionnel 



Premiere partie 



sd DSS Trailer le passage en caisse 



« system » 
:TPV 



Client SysAutoCheques SysAutoCartes 



C{Caissier authentifie et 
catalogue disponible} 



loop 



[pourchaque article] entrerUnArticlefcpu, quantite = 1) 



; verifierArticle(cpu 



K 



prix & description 



cloture rSaisie() 



total Vente 

;< _ -j 



Traiter le paiement 



terminerVente() 



enregistrerVente 



{Nouvelle vente 
enregistree) 



Figure 2-9. 

Version etendue du DSS 

du scenario nominal de Traiter le passage en caisse 

Notez que nous devons neanmoins faire figurer les acteurs secondaries pour assurer la 
coherence des lignes de vie entre les diagrammes 2-9 et 2-10. 



Le diagramme de sequence decrivant le cas d'utilisation Traiter le paiement est donne 
ci-apres. II utilise un fragment conditionnel (operateur alt). 
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Figure 2-10. 

DSS 

conditionnel 
du scenario 
nominal 
de Traiter le 
paiement 



sd Traiter le paiement 



«system 
:TPV 



:Client :SysAutoCheques :SysAutoCartes 



alt / 

[cash] 



[cheque]; 



saisiePaiementCash(montant) 



lisieldentite(ident) 



demandeAu^orisation 



[carteBancaire] 



saisieMontant(montant) 



demandeAutorisation 



En ce qui concerne le travail quotidien du caissier, il consiste a traiter le passage en 
caisse des clients successifs, apres s'etre authentifie en arrivant au magasin et avant de 
sortir de l'application en partant. Si nous voulons ajouter une contrainte de temps rela- 
tive aux 35 heures, soit une moyenne de 7 heures de travail consecutif par jour, nous 
obtenons le diagramme de sequence suivant. 



Figure 2-11. 

Diagramme de sequence du travail 
quotidien du caissier 



sd Travail quotidien du caissier 



« system » 
:TPV 



{t} 



I o g i n (p a sswo rd , u se rn a m e ) 



loop y 

[Pour tjhaque client] 



ref 










Traiter le pas; 


age 


en caisse 



{t+7h} 



logoutO 



Point de vue fonctionnel 



Premiere partie 



Etape 4 - Realisation d'un diagramme d'etats 
au niveau systeme 




Exercice 2-6. 

Diagramme d'etats des operations systeme 



Montrez par un diagramme d'etats la succession forcee des operations sys- 
teme pour le cas d'utilisation Traiter le passage en caisse, en ne considerant 
toujours que le paiement cash. Etendez ensuite le diagramme en prenant en 
compte les differents types de paiement, ainsi que les autres actions du 
caissier. 



J- 

O 



on 



Les operations systeme identifiees grace a l'exercice 2-4 correspondent aux 
trois messages 3 dont le systeme est destinataire : 



Figure 2-12. 

Operations systeme de 
Traiter le passage en caisse 



«system» 
Caisse 



saisieArticle(numero, quantite) 

finDeVente() 

saisiePaiement(montant) 



Pour representor la sequence forcee de ces trois operations systeme, avec la repetition 
possible de la saisie d'article, un diagramme d'etats s'impose 4 . II represente en fait le 
sous-ensemble des etats de la caisse induits par le cas d'utilisation Traiter le passage en 
caisse. 



3. Pour simplifier, nous n'avons pas pris en compte les deux messages d'annulation : annulerArticle et annulerVente . La 
demarche de prise en compte de ces deux messages serait identique : ajouter les transitions correspondantes sur le dia- 
gramme d'etats 2.13. 

4. UML 2 parle dans ce cas de machine a etats de type protocole (protocol state machine). Contrairement a une machine a 
etats de type comportement qui decrit les reactions d'un objet en reponse a des evenements, une machine a etats de type 
protocole specifie les sequences legales des evenements qui peuvent se produire dans le contexte d'une classe ou d'un 
composant. 
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Figure 2-13. 

Diagramme d'etats des 
operations systeme de Traiter 
le passage en caisse 



saisie paiement 



saisie article 




fin de vente 



Attente de 
paiement 



Si Ton tient compte des differents types de paiement, le diagramme d'etats devient lege- 
rement plus complexe. 



Figure 2-14. 

Diagramme d'etats 
complete des operations 
systeme de Traiter le 
passage en caisse 



Libre 



A 



autorisation[ OK ] 



Attente 
autorisation 



saisieArticle / 



saisieArticle 



> 



Enregistrement 
des articles 



saisiePat©ment[ liquide ] 



saisiePaiement[cheque ou CB ] 



finDeVente 



Attente 
paiement 



autorisation[ non OK ] 



Enfin, pour completer le diagramme d'etats de la caisse, independamment 
d'un cas d'utilisation particulier, il faudrait ajouter des etats supplementaires 
lies par exemple a 1' initialisation de la caisse, a la connexion du caissier, etc. 

Voici un exemple plus complet de ce que Ton pourrait alors obtenir, en gar- 
dant la restriction du paiement cash (done a comparer plutot a la figure 2-13) : 



Point de vue fonctionnel 



Premiere partie 




CONSEILS METHODOLOGIQUES 



COMMENT IDENTIFIER LES ACTEURS ? 

• Les acteurs sont a priori : 

- les utilisateurs humains directs : identifiez tous les profils possibles, sans 
oublier l'administrateur, l'operateur de maintenance, etc. ; 

- les autres systemes connexes qui interagissent aussi directement avec le 
systeme etudie, souvent par le biais de protocoles bidirectionnels. 

• Eliminez autant que faire se peut les acteurs « physiques » au profit des acteurs 
« logiques » : l'acteur est celui qui beneficie de l'utilisation du systeme. Cette 
regie permet en particulier de s'affranchir des technologies d'interface qui 
risquent d'evoluer au frl du projet et d'identifier des acteurs susceptibles d'etre 
mieux reutilises. 

• Repertoriez en tant qu' acteurs uniquement les entites externes (et pas des compo- 
sants internes au systeme etudie) qui interagissent directement avec le systeme (et 
pas indirectement par le biais d'autres acteurs). 
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• Ne confondez pas role et entite concrete. Une meme entite externe concrete peut 
jouer successivement differents roles par rapport au systeme etudie, et etre mode- 
lisee par plusieurs acteurs. Reciproquement, le meme role peut etre tenu simulta- 
nement par plusieurs entites externes concretes, qui seront alors modelisees par le 
meme acteur. 

COMMENT REPRESENTER LES ACTEURS ? 

Utilisez la forme graphique du stick man pour les acteurs humains, et la representation 
rectangulaire avec le mot-cle «actor» pour les systemes connectes. 

LE DIAGRAM ME DE CONTEXTE STATIQUE 

Realisez si necessaire un diagramme de contexte statique. II suffit pour cela d'utiliser un 
diagramme de classes dans lequel chaque acteur est relie par une association a une classe 
centrale unique representant le systeme, ce qui permet de specifier le nombre d'instances 
d' acteurs connectees au systeme a un moment donne. 

COMMENT IDENTIFIER LES CAS D'UTILISATION ? 

Utilisez la procedure systematique suivante : 

• delimitez le sujet : les frontieres du systeme a l'etude, son perimetre. S'agit-il 
d'une application logicielle, d'un systeme integrant du materiel et du logiciel, de 
cet ensemble plus son operateur ou l'organisation entiere qui l'opere ? 

• identifiez les acteurs principaux, c'est-a-dire ceux qui cherchent a obtenir un 
resultat observable, un but, en utilisant les services du systeme ; 

• identifiez les objectifs, les buts, de chaque acteur principal ; 

• definissez des cas d'utilisation autonomes qui correspondent aux objectifs des 
acteurs principaux. 

Ne vous inquietez pas : il est normal que tous les objectifs et les cas d'utilisation ne 
soient pas correctement identifies d'emblee. II s'agit forcement d'un processus de 
recherche iteratif et evolutif . 

COMMENT AMELIORER LE DIAGRAMME DE CAS D'UTILISATION ? 

Pour ameliorer le contenu informatif du diagramme de cas d'utilisation, nous recom- 
mandons d'adopter les conventions suivantes : 

• par defaut, le role d'un acteur est principal ; si ce n'est pas le cas, indiquez explici- 
tement que le role est secondaire sur 1' association, du cote de l'acteur ; 

• dans la mesure du possible, disposez les acteurs principaux a gauche des cas d'uti- 
lisation, et les acteurs secondaires a droite ; 



Point de vue fonctionnel 

Premiere partie 

• si l'acteur ne fait que recevoir des messages du systeme (ou seulement en 
envoyer), utilisez le symbole de restriction de navigabilite sur l'association entre 
le cas d'utilisation et l'acteur. 

COMMENT DECRIRE LES CAS D'UTILISATION ? 

• Pour detailler la dynamique du cas d'utilisation, la facon la plus simple de proce- 
der consiste a recenser textuellement toutes les interactions entre les acteurs et le 
systeme. Le cas d'utilisation doit avoir un debut et une fin clairement identifies. II 
faut egalement preciser les variantes possibles, telles que le scenario nominal, les 
differents cas « alternatif s » , les cas d'erreurs, tout en essayant d'ordonner 
sequentiellement les descriptions, afin d'ameliorer leur lisibilite. 

• Ne melangez pas cas d'utilisation essentiel (independant de tout choix technologique 
d'interface avec les acteurs) et cas d'utilisation reel : le premier est beaucoup plus 
stable et peut etre plus facilement reutilise. 

• Redigez avec concision en evitant les mots inutiles. Generalisez l'adoption de 
conventions communes au sein du projet. Celles proposees par A. Cockburn dans 
son ouvrage Rediger des cas d'utilisation efficaces [Cockburn 01] ont le merite 
d'etre largement repandues et acceptees. 

• Redigez des cas d'utilisation en « boite noire » : ne decrivez pas le fonctionne- 
ment interne du systeme, ses composants ou sa conception. Considerez unique- 
ment ce qui est visible par les acteurs. 

• Completez la description textuelle des cas d'utilisation par un ou plusieurs dia- 
grammes dynamiques UML : 

- Pour la dynamique globale du cas d'utilisation, utilisez un diagramme d'acti- 
vite ou un diagramme de sequence en profitant des nouvelles constructions 
UML 2 : fragments avec operateurs, references entre interactions. Vous pouvez 
egalement considerer le nouveau diagramme appele Interaction Overview 
Diagram, qui est une fusion du diagramme d'activite et du diagramme de 
sequence. 

- pour decrire le scenario nominal, utilisez un diagramme de sequence. 
Presentez-le en montrant l'acteur principal a gauche, puis un objet qui repre- 
sente le systeme en boite noire, et enfin en disposant a droite du systeme les 
eventuels acteurs secondares sollicites durant le scenario. 

• Vous pouvez enrichir le diagramme de sequence systeme du scenario nominal de 
facon a faire apparaitre egalement : 

- les principales actions internes du systeme (au moyen de messages qu'il 
s'envoie a lui-meme) ; 

- les renvois aux enchainements alternatif s et d'erreur (au moyen de notes) ; 

- les parties repetees, optionnelles ou alternatives (operateurs loop, opt et alt). 
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LES RELATIONS ENTRE CAS D'UTILISATION 

• Utilisez la relation d'inclusion entre cas d'utilisation pour eviter de devoir decrire 
plusieurs fois le meme enchamement, en factorisant ce comportement commun 
dans un cas d'utilisation supplementaire inclus. 

• Utilisez la relation d'extension entre cas d'utilisation pour separer un comporte- 
ment complexe optionnel ou rare du comportement obligatoire. 

• Utilisez la relation de generalisation/specialisation entre cas d'utilisation pour for- 
maliser des variations importantes sur le meme cas d'utilisation. 

• N'abusez cependant pas des relations entre cas d'utilisation (surtout extension et 
generalisation) : elles peuvent rendre les diagrammes de cas d'utilisation difficiles 
a decrypter pour les experts metier qui sont censes les valider. 

PAS PLUS DE 20 CAS D'UTILISATION ! 

Limitez a 20 le nombre de vos cas d'utilisation de base (en dehors des cas inclus, specia- 
lises, ou des extensions). Avec cette limite arbitraire, on reste synthetique et on ne tombe 
pas dans le piege de la granularite trop fine des cas d'utilisation. 

SOYEZ AGILES ET ITERATIFS ! 

Les descriptions textuelles des cas d'utilisation et les diagrammes UML ne sont jamais 
parfaits. II leur manque certains elements et certaines assertions sont fausses. La solution 
ne consiste pas a adopter 1' attitude du processus en cascade et a deploy er toujours plus 
d'efforts pour obtenir d'emblee des specifications exactes et exhaustives. II s'agit 
simplement de faire de notre mieux dans les delais impartis et en appliquant les 
meilleures pratiques. 

II existe un moyen terme entre la demarche en cascade et la programmation sauvage : le 
developpement iteratif et incremental. Dans cette approche, les cas d'utilisation et les 
autres modeles sont progressivement af fines, verifies et clarifies grace a la programma- 
tion et aux tests. 



Chapitre 

3 



Modelisation statique : 
etude de cas 



f> es 

■ Classe, objet ■ Operation ■ Association, multiplicity 

■ Attribut, attribut derive ■ Agregation, composition 

■ Classe d'association, qualificatif ■ Contrainte, 
metaclasse ■ Package ■ Generalisation, classe abstraite. 



Ce chapitre va nous permettre d'illustrer, pas a pas, a partir 
d'une nouvelle etude de cas, les principales difficultes que 
pose la construction des diagrammes de classes UML. 

Le diagramme de classes a toujours ete le diagramme le 
plus important dans toutes les methodes orientees objet. 
C'est celui que les outils de generation automatique de 
code utilisent en priorite. C'est egalement celui qui 
contient la plus grande gamme de notations et de 
variantes, d'ou la difficulty d'utiliser correctement tous ces 
concepts. 

Dans cet important chapitre, nous allons apprendre a : 

• Identifier les concepts du domaine et les modeliser en 
tant que classes, 

• Identifier les associations pertinentes entre les concepts, 
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• Reflechir aux multiplicities a chaque extremite d'association, 

• Ajouter des attributs aux classes du domaine, 

• Comprendre la difference entre modeles d'analyse et de 
conception, 

• Utiliser les diagrammes d'objets pour illustrer les dia- 
grammes de classes, 

• Utiliser les classes d'association, contraintes et qualificatifs, 

• Structurer notre modele en packages, 

• Comprendre ce qu'est un pattern d'analyse. 



Principes et definitions de base 



DIAGRAMME DE CLASSES 

Le diagramme de classes est le point central dans un developpement oriente objet. En 
analyse, il a pour objectif de decrire la structure des entites manipulees par les utilisateurs. 
En conception, le diagramme de classes represente la structure d'un code oriente objet ou, 
a un niveau de detail plus important, les modules du langage de developpement. 

Comment le representer ? 

Le diagramme de classes met en ceuvre des classes, contenant des attributs et des opera- 
tions, et reliees par des associations ou des generalisations. 



Figure 3-1. 

Exemple de diagramme i 



■ classes 



Classe A 



attribull 



operation - !)) 

A 



o 



Classe B 



attribut2 
attribut3 



operation20 
operation3Q 



Sous-classe A1 



operation4Q 
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CLASSE ET OBJET 

Une classe represente la description abstraite d'un ensemble d'objets possedant les 
memes caracteristiques. On peut parler egalement de type. 

Exemples : la classe Voiture, la classe Personne. 

Un objet est une entite aux frontieres bien definies, possedant une identite et encapsulant 
un etat et un comportement. Un objet est une instance (ou occurrence) d'une classe. 

Exemple : Pascal Roques est un objet instance de la classe Personne. Le livre que vous 
tenez entre vos mains est une instance de la classe Livre. 

ATTRIBUT ET OPERATION 

Un attribut represente un type d'information contenu dans une classe. 

Exemples : vitesse courante, cylindree, numero d'immatriculation, etc. sont des attributs 
de la classe Voiture. 

Une operation represente un element de comportement (un service) contenu dans une 
classe. Nous ajouterons plutot les operations en conception objet, car cela fait partie des 
choix d'attribution des responsabilites aux objets. 



ASSOCIATION 

Une association represente une relation semantique durable entre deux classes. 

Exemple : une personne peut posseder des voitures. La relation possede est une associa- 
tion entre les classes Personne et Voiture. 

Attention : meme si le verbe qui nomme une association semble privilegier un sens de 
lecture, une association entre concepts dans un modele du domaine est par defaut bidi- 
rectionnelle. Done implicitement, l'exemple precedent inclut egalement le fait qu'une 
voiture est possedee par une personne. 

Comment les representer ? 

Aux deux extremites d'une association, on doit faire figurer une indication de multipli- 
cite. Elle specifie sous la forme d'un intervalle d'entiers positifs ou nuls le nombre 
d'objets qui peuvent participer a une relation avec un objet de l'autre classe dans le cadre 
d'une association. 

Exemple : une personne peut posseder plusieurs voitures (entre zero et un nombre 
quelconque) ; une voiture est possedee par une seule personne. 



Point de vue statique 



DEUXIEME PARTIE 



Figure 3-2. 

Exemples de multiplicity d'association 





possede 




Personne 


Voiture 




1 0..* 





AGREGATION ET COMPOSITION 

Une agregation est un cas particulier d'association non symetrique exprimant une rela- 
tion de contenance. Les agregations n'ont pas besoin d'etre nominees : implicitement 
elles signifient « contient », « est compose de ». 

Une composition est une agregation plus forte impliquant que : 

• un element ne peut appartenir qu'a un seul agregat composite (agregation non 
partagee) ; 

• la destruction de 1' agregat composite entraine la destruction de tous ses elements 
(le composite est responsable du cycle de vie des parties). 

Comment les representer ? 



Figure 3-3. 

Exemples d' agregation 
et de composition 





Element 


* 


0..* 





Composite 





Element 


0..* 





GENERALISATION, SUPER-CLASSE, SOUS-CLASSE 

Une super-classe est une classe plus generale reliee a une ou plusieurs autres classes plus 
specialisees (sous-classes) par une relation de generalisation. Les sous-classes 
« heritent » des proprietes de leur super-classe et peuvent comporter des proprietes 
specifiques supplementaires. 



Exemple : les voitures, les bateaux et les avions sont des moyens de transport. lis posse- 
dent tous une marque, un modele, une vitesse, etc. Par contre, seuls les bateaux ont un 
tirant d'eau et seuls les avions ont une altitude. . . 
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Figure 3-4. 

Exemple de super-classe 
et sous-classes 



Moyen de transport 



marque 
modele 
vitesse 
vitesse max 




Bateau 

tirant d'eau 
nombre de voiles 




Une classe abstraite est simplement une classe qui ne s'instancie pas directement mais 
qui represente une pure abstraction afin de factoriser des proprietes communes. Elle se 
note en italique. C'est le cas de Moyen de Transport dans l'exemple precedent. 

PACKAGE 

Package : mecanisme general de regroupement d'elements en UML, qui est principale- 
ment utilise en analyse et conception objet pour regrouper des classes et des associa- 
tions. Les packages sont des espaces de noms : deux elements ne peuvent pas porter le 
meme nom au sein du meme package. Par contre, deux elements appartenant a des 
packages differents peuvent porter le meme nom. 

La structuration d'un modele en packages est une activite delicate. Elle doit s'appuyer 
sur deux principes fondamentaux : coherence et independance . 

Le premier principe consiste a regrouper les classes qui sont proches d'un point de vue 
semantique. Un critere interessant consiste a evaluer les durees de vie des instances de 
concept et a rechercher l'homogeneite. Le deuxieme principe s'efforce de minimiser les 
relations entre packages, c'est-a-dire plus concretement les relations entre classes de 
packages differents. 
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Figure 3-5. 

Exemples de packages 
contenant des classes 



Clientele 



Personne 



nom 
adresse 



possede 



Voitures 



0..* 



Voiture 



marque 
modele 

numerolmmatriculation 



0..1 
4 

Roue 



Etude d'un systeme de reservation de vol 



Cette etude de cas concerne un systeme simplifie de reservation de vols pour une agence 
de voyages. 

Les interviews des experts metier auxquelles on a procede ont permis de resumer leur 
connaissance du domaine sous la forme des phrases suivantes : 

1 . Des compagnies aeriennes proposent differents vols. 

2. Un vol est ouvert a la reservation et referme sur ordre de la compagnie. 

3 . Un client peut reserver un ou plusieurs vols , pour des passagers differents . 

4. Une reservation concerne un seul vol et un seul passager. 

5 . Une reservation peut etre annulee ou confirmee. 

6. Un vol a un aeroport de depart et un aeroport d'arrivee. 

7. Un vol a un jour et une heure de depart, et un jour et une heure d'arrivee. 

8 . Un vol peut comporter des escales dans des aeroports . 

9. Une escale a une heure d'arrivee et une heure de depart. 

10. Chaque aeroport dessert une ou plusieurs villes. 

Nous allons entreprendre progressivement la realisation d'un modele statique d'analyse 
(aussi appele modele du domaine) a partir de ces « morceaux de connaissance ». 
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Etape 1 - Modelisation des phrases 1 et 2 

En premier lieu, nous allons modeliser la premiere phrase : 
1 . Des compagnies aeriennes proposent differents vols. 

CompagnieAerienne et Vol sont des concepts importants du monde reel ; ils ont des 
proprietes et des comportements. Ce sont done des classes candidates pour notre mode- 
lisation statique. 

Nous pouvons initier le diagramme de classes comme suit : 



Figure 3-6. 

Modelisation de la phrase 1 



CompagnieAerienne 


propose 


Vol 


1..* 







La multiplicite « 1. * » du cote de la classe Vol a ete preferee a une multiplicite « 0..* » 
car nous ne gerons que les compagnies aeriennes qui proposent au moins un vol 1 . 

En revanche, la phrase ne nous donne pas d'indication sur la multiplicite du cote de 
la classe CompagnieAerienne . C'est la une premiere question qu'il faudra poser a 
1' expert metier. 

Par la suite, nous partirons du principe qu'un vol est propose le plus souvent par une 
seule compagnie aerienne, mais qu'il peut egalement etre partage entre plusieurs affre- 
teurs. Au passage, on notera que le terme « affreteur » est un bon candidat pour nommer 
le role joue par la classe CompagnieAerienne dans l'association avec Vol. 



Figure 3-7. 

Modelisation completee de 
la phrase 1 



CompagnieAerienne 


1.. propose 1..* 


Vol 


affreteur 











Nous allons maintenant nous interesser a la deuxieme phrase. Les notions d'ouverture et 
de fermeture de la reservation represented des concepts dynamiques. II s'agit en effet de 
changements d'etat d'un objet Vol sur ordre d'un objet CompagnieAerienne. Une solu- 
tion naturelle consiste done a introduire un attribut enumere etat, comme cela est montre 
sur la figure suivante. 



1 . Ceci est typique de la modelisation du domaine. En conception, nous utiliserons plutot « 0..* », car lorsque Ton ajoute 
un objet CompagnieAerienne dans le systeme, il n'existe pas encore d'instances de Vol associees. 
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Figure 3-8. 

Premiere 
modelisation 
de la phrase 2 



CompagnieAerienne 



1..* 



propose 



affreteur 



Vol 



<^ etat :( ouvert, ferme) ^ 



Neanmoins cette approche est discutable : tout objet possede en effet un etat courant, en 
plus des valeurs de ses attributs. Cela fait partie des proprietes intrinseques des concepts 
objets. La notion d'etat ne devrait done pas apparaitre directement en tant qu'attribut sur 
les diagrammes de classes : elle sera plutot modelisee dans le point de vue dynamique 
grace au diagramme d'etats (voir chapitres 5 et 6). Dans le diagramme de classes UML, 
les seuls concepts dynamiques disponibles sont les operations 2 . 

Or, les debutants en modelisation objet ont souvent du mal a placer les operations dans 
les bonnes classes ! Plus generalement, l'assignation correcte des responsabilites aux 
bonnes classes est une qualite distinctive des concepteurs objets experimentes. . . 

EXERCICE 3-1. 

Placement des operations dans les classes 



Dans quelle classe placez-vous les operations que Ton vient d'identifier ? 



<>° n 

O Qui est ouvert a la reservation ? C'est le vol, et non pas la compagnie. 

~o 

^\ En oriente objet, on considere que l'objet sur lequel on pourra realiser un traitement 
doit le declarer en tant qu'operation. Les autres objets qui possederont une reference 
dessus pouiTont alors lui envoyer un message qui invoque cette operation. 

II faut done placer les operations dans la classe Vol, et s' assurer que la classe Com- 
pagnieAerienne a bien une association avec elle. 



Figure 3-9. 

Modelisation 

correcte 

de la phrase 2 





propose 


Vol 


CompagnieAerienne 


1..* i..y 


ouvrirReservationO^ 
fermerReservationO, 









L'association propose s'instanciera en un ensemble de liens entre des objets des 
classes CompagnieAerienne et Vol. 

2. II est a noter que certains auteurs (comme Larman) preconisent de reporter 1' identification des operations a l'etape de 
conception. Dans le modele d'analyse, appele souvent modele du domaine, ils ne representent que les concepts du 
domaine, leurs attributs et leurs relations statiques (associations et generalisations). Nous nous placons dans une pers- 
pective plus large a des fins pedagogiques. 
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Elle pemiettra done bien a des messages d'ouverture et de fermeture de reservation 
de circuler entre ces objets, comme cela est indique sur le diagramme de communi- 
cation 3 ci-apres. 



Figure 3-10. 

Diagramme de 
communication 
illustrant la phrase 2 



1 : ouvrirReservation( ) 
2: fermerReservation( ) 




V1 :Vol 


: CompagnieAerienne 




3: ouvrirReservation( ) 


V2 : Vol 



Etape 2 - Modelisation des phrases 6, 7 et 10 



Poursuivons la modelisation de la classe Vol. Les phrases 6 et 7 s'y rapportent directe- 
ment. Considerons tout d'abord la phrase 7 : 

7. Un vol a un jour et une heure de depart et un jour et une heure d'arrivee. 

Toutes ces notions de dates et d'heures represented simplement des valeurs pures. Nous 
les modeliserons done comme des attributs et pas comme des objets a part entiere. 



CompagnieAerienne 



Figure 3-11. 

Modelisation des phrases 1,2 et 7 



propose 



Vol 

dateDepart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservation() 
fermerReservation() 



Un objet est un element plus « important » qu'un attribut. Un bon critere a appliquer en la 
matiere peut s'enoncer de la facon suivante : si Ton ne peut demander a un element que sa 
valeur, il s'agit d'un simple attribut ; si plusieurs questions s'y appliquent, il s'agit plutot 
d'un objet qui possede lui-meme plusieurs attributs, ainsi que des liens avec d'autres objets. 

Essayez d'appliquer ce principe a la phrase 6 : 

6. Un vol a un aeroport de depart et un aeroport d'arrivee. 



3 . Le diagramme de communication (appele collaboration en UML 1 .x) montre comment des instances envoient des mes- 
sages a d'autres instances. Pour qu'un message puisse etre recu par un objet, une operation de meme nom doit etre 
declaree publique dans la classe concernee. 
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EXERCICE 3-2. 

Associations multiples entre classes 



Quelles sont les differentes solutions pour modeliser la phrase 6, avec leurs 
avantages et inconvenients ? 



J- 

O 



on 



Contrairement aux notions d'heure et de date qui sont des types « simples », la 
notion d' aeroport est complexe ; elle fait partie du « metier ». Un aeroport ne 
possede pas seulement un nom, il a aussi une capacite, dessert des villes, etc. C'est 
la raison pour laquelle nous preferons creer une classe Aeroport plutot que de 
simples attributs aeroportDepart et aeroportArrivee dans la classe Vol. 

Une premiere solution consiste a creer une association avec une multiplicite 2 du 
cote de la classe Aeroport. Mais nous perdons les notions de depart et d'arrivee. 
Une astuce serait alors d'ajouter une contrainte {ordered} du cote Aeroport, pour 
indiquer que les deux aeroports lies au vol sont ordonnes (l'arrivee a toujours lieu 
apres le depart !). 



Figure 3-12. 

Solution approximative 
de la phrase 6 



Vol 



dateDepart 
heure Depart 
dateArrivee 
heureArrivee 
~~ -aexp_portDepart^_ 
aejBpoffATtwee^ 



ouvrirReservation() 
fermerReservation() 



{ordered} 



Aeroport 



II s'agit la d'une modelisation « tordue » que nous ne recommandons pas, car elle 
n'est pas tres parlante pour l'expert metier et il existe une bien meilleure solution. . . 

Une autre solution tentante consiste a creer deux sous-classes de la classe Aeroport. 



Figure 3-13. 

Solution incorrecte 
de la phrase 6 



Vol 



dateDepart 

heureDepart 

dateArrivee 

heureArrivee 
- -aeiBDortDeparr^ 
_ aBfopo?!ATH\ige- — 



ouvrirReservation() 
fermerReservationQ 




AeroportDepart 



AeroportArrivee 





Aeroport 




nom 
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Pourtant, cette solution est incorrecte ! En effet, tout aeroport est successivement 
aeroport de depart pour certains vols et aeroport d'arrivee pour d'autres. Les classes 
AeroportDepart et AeroportArrivee ont done exactement les memes instances 
redondantes, ce qui devrait decourager d'en faire deux classes distinctes. 

Le concept UML de role s'applique parfaitement dans cette situation. La facon la 
plus precise de proceder consiste done a creer deux associations entre les classes Vol 
et Aeroport, chacune affectee d'un role different avec une multiplicite egale a 1 
exactement. 

Figure 3-14. 

Modelisation 
correcte de la 
phrase 6 




A retenir DATE COMME TYPE NON PRIMITIF 

Nous avons explique precedemment pourquoi nous preferons modeliser 
les dates et heures comme des attributs et pas des objets, contraire- 
ment aux aeroports. 

Une solution plus sophistiquee a ete proposee par M. Fowler 3 : el le 
consiste a creer une classe Date et a s'en servir ensuite pour typer 
I'attribut au lieu d'ajouter une association. 




a. Analysis Patterns: Reusable Object Models, M. Fowler, 1997, Addison-Wesley. 
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A retenir DIFFERENCE ENTRE MODELE D'ANALYSE ET DE CONCEPTION 



Dans le code Java de I'application finale, il est certain que nous utilise- 
rons explicitement la classe d'implementation Date (du package 
java . utll). 



Vol 


^ 1 


java.util::Date 


'fJateDepart^ ,>, y--' 
Jjeu re Depart/ 

OateArrivee 
heureArrivee J 


— 

dateDepart 

1 




+ getDay() : int 

+ getHours() : int 

+ getMinutes() : int 

+ before(argO : Date) : boolean 

+ afterfargO : Date) : boolean 

+ getTimezoneOffset() : int 


ouvrirReservation() 
fermerReservation() 


dateArrivee 



II ne s'agit pas la d'une contradiction, mais d'une difference de niveau 
d'abstraction, qui donne lieu a deux modeles differents, un modele 
d'analyse et un modele de conception detaillee, pour des types de 
lecteurs et des objectifs distincts. 



EXERCICE 3-3. 

Discussion sur les multiplicites 

Nous pouvons maintenant passer a la modelisation de la phrase 10. 
10. Chaque aeroport dessert une ou plusieurs villes. 



Figure 3-15. 

Modelisation de la phrase 10 



Aeroport 


dessert 


Ville 


1..* 







Cependant, nous constatons une fois encore que la phrase 10 ne traduit qu'un seul sens 
de l'association. Elle ne permet pas de determiner la multiplicite du cote de la classe 
Aeroport. La question doit done etre formulee de la facon suivante : par combien d'aero- 
ports une ville est-elle desservie ? 

Quelle est la multiplicite du cote aeroport pour la modelisation de la phrase 10 ? 
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on 

La question est moins triviale qu'il n'y parait au premier abord. . . Tout depend en 
O effet de la definition exacte que Ton prete au verbe « desservir » dans notre 
^ systeme ! En effet, si « desservir » consiste simplement a designer le moyen de 
transport par les airs le plus proche, toute ville est toujours desservie par un et un 
seul aeroport. 



Figure 3-16. 

Modelisation possible 
de la phrase 10 



Aeroport 



dessert 


Ville 


) 







Mais si « desservir » vaut par exemple pour tout moyen de transport aerien se trouvant a 
moins de trente kilometres, alors une ville peut etre desservie par 0 ou plusieurs aero- 
ports. 

C'est cette derniere definition que nous retiendrons. 



Figure 3-17. 

Modelisation completee 
de la phrase 10 



Aeroport 



dessert 



Ville 



Etape 3 - Modelisation des phrases 8 et 9 



Considerons maintenant les escales, c'est-a-dire les phrases 8 et 9. 

8. Un vol peut comporter des escales dans des aeroports. 

9. Une escale a une heure d'arrivee et une heure de depart. 

Chaque escale a deux proprietes d'apres la phrase 9 : heure d'arrivee et heure de depart. 
Elle est egalement en relation avec des vols et des aeroports, qui sont eux-memes des 
objets, d'apres la phrase 8. II est done naturel d'en faire une classe a son tour. 

Cependant, la phrase 8 est aussi imprecise : une escale peut-elle appartenir a plusieurs 
vols, et quelles sont les multiplicites entre Escale et Aeroport ? De plus, le schema 
n'indique toujours pas les multiplicites du cote Vol avec Aeroport. 
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Figure 3-18. 

Modelisation preliminaire 
des phrases 8 et 9 



Vol 



dateDepart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservation() 
fermerReservation() 



depart 



arrivee 



Aeroport 



nom 



comporte 


Escale 




0..* 


heureArrivee 
heureDepart 







EXERCICE 3-4. 

Nouvelle discussion sur les multiplicites 

Completez les multiplicites des associations. 



D'apres la phrase 8, un vol peut comporter des escales dans des aeroports. Cette for- 
O mulation est ambigue, et vaut que Ton y refiechisse un peu, en faisant meme appel 
aux conseils d'un expert metier. 

On peut commencer par ajouter les multiplicites entre Escale et Aeroport, ce qui 
doit etre aise. II est clair qu'une escale a lieu dans un et un seul aeroport, et qu'un 
aeroport peut servir a plusieurs escales. De meme, un aeroport peut servir de depart 
ou d'anivee a plusieurs vols. 

On pourrait egalement penser qu'une escale n'appartient qu'a un vol et un seul, 
mais est-ce bien certain ? Apres consultation de l'expert metier, un contre-exemple 
nous est donne, sous forme du diagramme d'objets suivant. 
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Figure 3-19. 

Diagramme d'objets 
Ulustrant la phrase 8 



ToulouseMinorque : Vol 



depart 



Palma : Aeroport 



QxMinorque : Vol 



depart 



Blaqnac : Aeroport 




Bordeaux : Escale 



Meriqnac : Aeroport 



Minorque : Aeroport 



Une escale peut done appartenir a deux vols differents, en particulier quand ces vols 
sont « imbriques ». Notez combien il est efficace de recourir au diagramme d'objets 
pour dormer un exemple, ou encore un contre-exemple, qui permette d'affiner un 
aspect delicat d'un diagramme de classes. 

Pour finaliser le diagramme des phrases 8 et 9, il nous sufiit d'ajouter deux 
precisions : 

• l'association entre Vol et Escale est une agregation (mais certainement pas 
une composition, puisqu'elle est partageable) ; 

• les escales sont ordonnees par rapport au vol. 



Figure 3-20. 

Modelisation complete 
des phrases 8 et 9 



Vol 



date Depart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservationO 
fermerReservation() 



JET 



0. 



{ordered} 



depart 



arnvee 



Aeroport 



nom 



Escale 



heureArrivee 
eureDepart 



a lieu dans 
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EXERCICE 3-5. 

Classe d'association 



Dans la solution precedente, la classe Escale sert d'intermediaire entre les classes Vol et 
Aeroport. Elle a peu de realite par elle-meme, et cela nous laisse done penser a une autre 
solution la concernant... 



Proposez une solution plus sophistiquee pour la modelisation des escales. 



Au vu du diagramme precedent, il apparait que la classe Escale comporte peu 
O d'informations propres ; elle est fortement associee a Aeroport (multiplicite 1) et 
vT* n'existe pas par elle-meme, mais seulement en tant que partie d'un Vol. 

Une premiere idee consiste a considerer Escale comme une specialisation de 
Aeroport. 



Figure 3-21. 

Modelisation avec 
heritage des phrases 8 et 9 



Vol 



dateDepart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservation() 
fermerReservation( 



depart 



1 



0..* 



{ordered} 



0.. 



Aeroport 



nom 



TV 



heureDepart 
heureArrivee 



II s'agit la d'une solution seduisante, l'escale recuperant automatiquement 
par heritage le nom d'aeroport, et ajoutant par specialisation les heures de 
depart et d'arrivee. 

Pourtant, on ne peut pas recommander d'y recourir. En effet, peut-on vraiment dire 
qu'une escale est une sorte d'aeroport, peut-on garantir que la classe Escale est con- 
forme a 100 % aux specifications de sa super-classe ? Est-ce qu'une escale dessert 
des villes, est-ce qu'une escale peut servir de depart ou d'arrivee a un vol ? Si Ton 
ajoute des operations ouvrir etfermer a la classe Aeroport, s'appliqueront-elles a 
Escale ? II ne s'agit done pas, a vrai dire, d'un heritage d'interface, mais bien plutot 
d'une facilite dont pourrait user un concepteur peu scrupuleux pour recuperer auto- 
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matiquement l'attribut nom de la classe Aeroport, avec ses futures methodes 
d'acces. Cette utilisation de l'heritage est appelee un heritage d'implementation et 
elle est de plus en plus largement deconseillee. En outre, si Ton veut un jour specia- 
liser au sens metier les aeroports en aeroports internationaux et regionaux, par 
exemple, on devra rapidement gerer un heritage multiple. 

Pourquoi ne pas considerer plutot cette notion d'escale comme un troisieme role 
joue par un aeroport par rapport a un vol ? Les attributs heureArrivee et heureDe- 
part deviennent alors des attributs d'association, comme cela est montre sur le 
schema suivant. La classe Escale disparait alors en tant que telle, et se trouve rem- 
placee par une classe d'association InfosEscale. 



Figure 3-22. 

Modelisation plus sophistiquee 
des phrases 8 et 9 



Vol 



dateDepart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservation() 
fermerReservationO 



depart 



0..* 


1 






arrivee 


0..* 


1 


escale 



Aeroport 



InfosEscale 



heureDepart 
heureArrivee 




On pourrait pousser le raisonnement un cran plus loin et decider que les attri- 
buts dateDepart et heureDepart appartiennent a 1' association Vol - depart, et 
que dateArrivee et heureArrivee appartiennent a 1' association Vol - arrivee. 
On obtiendrait ainsi un modele plus homogene avec trois classes dissocia- 
tions . Nous decidons cependant de garder la solution de la figure precedents 
pour des raisons de simplicity . 

Etape 4 - Modelisation des phrases 3, 4 et 5 



Nous pouvons maintenant aborder le traitement du concept de reservation. 
Relisons bien les phrases 3 a 5 qui s'y rapportent directement. 

3. Un client peut reserver un ou plusieurs vols, pour des passagers differents. 

4. Une reservation concerne un seul vol et un seul passager. 

5. Une reservation peut etre annulee ou confirmee. 

Une question preliminaire peut se poser immediatement. . . 
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EXERCICE 3-6. 

Distinction entre concepts 

Faut-il vraiment distinguer les concepts de client et de passager ? 



Au premier abord, cette distinction peut paraitre superflue, mais elle est en fait 
O absolument necessaire ! Prenons le cas des deplacements professionnels : le 
vf* client est souvent l'employeur de la personne qui se deplace pour son travail. 
Cette personne joue alors le role du passager et apprecie de ne pas devoir avancer 
le montant de son billet. Le concept de client est fondamental pour les aspects 
facturation et comptabilite, alors que le concept de passager est plus utile pour les 
aspects lies au vol lui-meme (embarquement, etc.). 



D'apres la phrase 4, une reservation concerne un seul vol et un seul passager. 
Nous pouvons modeliser cela directement par deux associations. 

La phrase 5, quant a elle, se traduit simplement par l'ajout de deux operations 
dans la classe Reservation, sur le modele de la phrase 2. 



Figure 3-23. 

Modelisation directe 
des phrases 4 et 5 



Reservation 



annuler() 
confirmed) 



concerne 



concerne 



1 



Passager 



Vol 



dateDepart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservation() 
fermerReservationQ 



Notez neanmoins qu'une solution plus concise est possible, a savoir considerer le 
passager comme un simple attribut de Reservation. Linconvenient majeur concerne 
la gestion des informations sur les passagers. En effet, il est fort probable que Ton 
ait besoin de gerer les coordonnees du passager (adresse, telephone, e-mail, etc.), 
voire des points de fidelite, ce que ne permet pas facilement la solution simpliste 
montree sur la figure suivante. 
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Figure 3-24. 

Modelisation simpliste 
des phrases 4 et 5 



0 



Reservation 
nomPassager ) 



anrultsrt) 
confirmerQ 



concerne 



Vol 



dateDepart 
heureDepart 
dateArrivee 
heureArrivee 



ouvrirReservation() 
fermerReservation() 



Nous conserverons done l'approche faisant de Passager une classe a part entiere. 



EXERCICE 3-7. 

Modelisation de la reservation 

Poursuivons notre traitement du concept de reservation. La phrase 3 est un peu plus deli- 
cate, a cause de sa formulation alambiquee. 



Modelisez la phrase 3 et completez les multiplicites des associations precedentes. 



O Le debut de la phrase 3 peut preter a confusion en raison de la relation directe qu'il 
O semble impliquer entre client et vol. En fait, le verbe « reserver » masque le concept 
vT* deja identifie de reservation. Nous avons vu lors de la modelisation de la phrase 4 
qu'une reservation concerne un seul vol. Le debut de la phrase 3 peut done se refor- 
muler plus simplement : un client peut effectuer plusieurs reservations (chacune 
portant sur un vol). Ce qui se traduit directement par le schema suivant. 



Figure 3-25. 

Debut de modelisation de la phrase 3 



Client 


a effectue 


Reservation 




0..* 


annuler() 
confirmer() 







concerne 



Vol 
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Nous allons completer le diagramme en ajoutant d'abord les deux multiplicites 
manquantes. II est clair qu'une reservation a ete effectuee par un et un seul client, et qu'un 
meme vol peut etre concerne par zero ou plusieurs reservations. Ajoutons ensuite la classe 
Passager et completons les multiplicites. Combien de reservations un meme passager 
peut-il avoir ? Au premier abord, au morns une, sinon il n'est pas passager. En fait, nous 
gerons des reservations, pas le vol lui-meme. Nous avons done besoin de stocker des 
instances persistantes de passagers, meme s'ils n'ont pas tous de reservation a l'instant 
courant. Encore une question de point de vue de modelisation ! Pour l'application qui gere 
l'embarquement, un passager a une et une seule reservation, mais ici il faut prevoir « 0..* ». 



Figure 3-26. 

Modelisation complete des phrases 4 et 5 



Client 



1 a effectue 0.. 



concerne 



Passager 1 



Reservation 



annuler() 
confirmerQ 



concerne 



Vol 



Pour completer, notons que nous pourrions egalement representer Reservation 
comme une classe d'association entre Vol et Passager. Quoique egalement correcte, 
nous ne conserverons pas cette derniere solution ann de ne pas complexifier inutile- 
ment les diagrammes suivants. 



Reservation 



annuler() 
confirmerQ 



effectuee par 



1 



Client 



Figure 3-27. 


Passager 


0..* 


0..* 


Vol 


Modelisation alternative des phrases 4 et 5 


1 



Etape 5 - Ajout d'attributs, de contraintes et de qualificatifs 



Le modele que Ton obtient par la modelisation des 10 phrases de l'enonce ressemble 
actuellement au diagramme de la figure presentee ci-apres. 
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Figure 3-28. 

Modelisation prel iminaire 
du systeme de reservation 
de vols 



CompagnieAerienne 
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heureDepart 
heureArrivee 
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date Arrivee 
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fermerReservationQ 


* 

escale x 



1 

0..* 



annuler{) 
confirmed) 



Certaines classes n'ont pas d'attribut, ce qui est plutot mauvais signe pour un modele 
d' analyse representant des concepts metier. La raison en est simplement que nous 
n'avons identifie que les attributs qui sont directement issus des phrases de l'enonce. II 
en manque done certainement. . . 



~ EXERCICE 3-8. 

Ajout d'attributs metier 



Ajoutez les attributs metier qui vous semblent indispensables. 

^ Pour chacune des classes, nous repertorions ci-apres les attributs indispensables. 



O 



Attention ! On ne doit pas lister dans les attributs des references a d'autres classes 
e'est le but meme de ridentification des associations. 

Aeroport : 

• nom 

Client : 

• nom 

• prenom 

• adresse 

• numTel 

• numFax 

CompagnieAerienne : 

• nom 
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InfosEscale : 

• heureDepart 

• heureArrivee 

Passager : 

• nom 

• prenom 

Reservation : 

• date 

• numero 

Ville : 

• nom 

Vol: 

• numero 

• dateDepart 

• heureDepart 

• dateArrivee 

• heureArrivee 

On notera que c'est la convention de nommage recommandee par les auteurs d'UML 
qui est utilisee ici. Cette convention n'est cependant pas obligatoire. Si vous devez faire 
valider votre modele par un expert metier, preferez une convention plus « naturelle » 
avec espaces, accents, etc. 

A retenir CONVENTIONS DE NOMMAGE EN UML 

Les noms des attributs commencent toujours par une minuscule 
(contrairement aux noms des classes qui commencent systematique- 
ment par une majuscule) et peuvent contenir ensuite plusieurs mots 
concatenes, commencant par une majuscule. 

II est preferable de ne pas utiliser d'accents ni de caracteres speciaux. 

Les memes conventions s'appliquent au nommage des roles des asso- 
ciations, ainsi qu'aux operations. 



EXERCICE 3-9. 

Ajout d'attributs derives 

Completez le modele avec quelques attributs derives pertinents. 
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O 



on 



Un attribut derive est une propriete valuee interessante pour l'analyste, mais redon- 
dante, car sa valeur peut etre deduite d'autres informations disponibles dans le 
modele. 

Un bon exemple en est fourni par la notion de duree d'un vol. En effet, il est clair 
que cette information est importante : le client voudra certainement connaitre la 
duree de son vol, sans qu'il doive la calculer lui-meme ! Le systeme informatique 
doit etre capable de gerer cette notion. Or, les informations necessaires pour cela 
sont deja disponibles dans le modele grace aux attributs existants relatifs aux 
dates et heures de depart et d'arrivee. II s'agit done bien d'une information deri- 
vee. Le meme raisonnement s'applique pour la duree de chaque escale. 

Le diagramme presente ci-apres recapitule le nouvel etat de notre modele avec tous 
les attributs. 



Figure 3-29. 

Ajout ties attributs metier 
et derives 
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A retenir ATTRIBUT DERIVE EN CONCEPTION 

Les attributs derives permettent a l'analyste de ne pas faire de choix de 
conception premature. Cependant, ce concept n'existant pas dans les 
langages objets, le concepteur va etre amene a choisir entre plusieurs 
solutions : 

- Garder un attribut « normal » en conception, qui aura ses methodes 
d'acces [get et set) comme les autres attributs : il ne faut pas oublier 
de declencher la mise a jour de I'attribut des qu'une information dont 
il depend est modifiee. 
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- Ne pas stocker la valeur redondante, mais la calculer a la demande au 
moyen d'une methode publique. 

La seconde solution est satisfaisante si la frequence de requete est 
faible, et I'algorithme de calcul simple. La premiere approche est neces- 
saire si la valeur de I'attribut derive doit etre disponible en permanence, 
ou si le calcul est tres complexe et couteux. Comme toujours, le choix 
du concepteur est une affaire de compromis... 



Analyse 



InfosEscale 



heureDepart 
heureArrivee 
/ duree 



Conception 



InfosEscale 



heureDepart 
heureArrivee 



+ calculerDuree 



P 




EXERCICE 3-10. 

Ajout de contraintes et de qualificatifs 



Affinez encore le diagramme en ajoutant des contraintes et une association qualifiee. 

^ II est possible que Ton trouve un grand nombre de contraintes sur un diagramme de 
O classes. Mieux vaut les repertorier de facon exhaustive dans le texte qui accompa- 
vT* gne le modele, et choisir avec soin les plus importantes, que Ton pourra alors faire 

figurer sur le diagramme. On encourt sinon le risque de surcharger le schema et de 

le rendre illisible. 

Sur note exemple, nous avons choisi de montrer les contraintes les plus fortes entre 
les attributs. Elles correspondent a des regies de gestion qui devront etre implemen- 
tees dans le systeme informatique final. 

Nous avons egalement insiste sur le fait qu'une reservation concerne bien un seul vol 
et un seul client, et qui plus est de facon irreversible. Pour changer de vol ou de client, 
il faut annuler la reservation en question, et en creer une nouvelle. Cela se traduit en 
UML par les contraintes {frozen}^ sur les roles des associations concernees. 

Enfin, nous avons transforme l'attribut numero de la classe Vol en qualificatif de 
l'association propose entre les classes CompagnieAerienne et Vol. En effet, cha- 
que vol est identifie d'une facon unique par un numero propre a la compagnie. 
Notez comme 1' ajout du qualificatif reduit la multiplicite du cote de la classe 
Vol. La figure presentee ci-apres montre le diagramme de classes complete. 



4. Meme si {frozen} semble avoir disparu de la liste des contraintes predefinies dans les documents qui decrivent UML 2, 
nous continuerons a utiliser cette notation interessante. 
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Ajout des 

contraintes 

et du qualiflcatif 
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Etape 6 - Utilisation de patterns d'analyse 



Notre modele peut encore etre notablement ameliore ! 

Reprenons a cet effet par le detail les elements qui concernent la classe Vol, tels qu'ils 
sont represented sur la figure suivante. 



Figure 3-31. 

Detail du modele autour 
de la classe Vol 
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Ne vous semble-t-il pas que la classe Vol a beaucoup de responsabilites differentes, 
avec tous ses attributs et toutes ses associations ? Elle viole un principe important de 
la conception orientee objet, appele par certains auteurs, forte cohesion. 
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EXERCICE 3-11. 

Pattern de la metaclasse 



Proposez une solution plus sophistiquee pour la modelisation des Vols. 



J- 

O 



on 



La classe Vol du diagramme precedent possede deux differents types de 
responsabilites : 

• Le premier concerne tout ce qui se retrouve dans les catalogues des compa- 
gnies aeriennes : oui, il existe bien un Toulouse-Paris Orly sans escale, tous 
les lundis matin a 7 h 10, propose par Air France. . . II s'agit la de vols gene- 
riques, qui reviennent a l'identique, toutes les semaines, ou presque. 

• Le second rassemble ce qui touche aux reservations. Vous ne reservez pas 
un Toulouse-Paris Orly du lundi matin, mais bien le Toulouse-Paris Orly du 
05 Juin 2006 ! 



Figure 3-32. 

Separation des 
responsabilites de la 
classe Vol 




Reservation 



concerne 



{frozen} 



date 
numero 



annulerQ 
confirmed) 



On peut y voir une sorte de relation d'instanciation, entre une classe VolGenerique 
restreinte au premier type de responsabilites, et une classe Vol qui rassemble les res- 
ponsabilites du second type. 

En effet, un vol generique decrit une fois pour toutes des proprietes qui seront iden- 
tiques pour de nombreux vols reels. 

De meme, supposons qu'une compagnie annule tous ses prochains vols du week- 
end au depart de l'aeroport X, car celui-ci est indisponible jusqu'a nouvel ordre, en 
raison d'importants travaux de maintenance effectues le samedi et le dimanche. 
Cela signifie dans notre premiere solution que nous allons detruire toutes les instan- 
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ces correspondantes de la classe Vol. A la fin de la periode de maintenance de 
l'aeroport X, il nous faudra recreer les instances de Vol avec leurs attributs valorises 
et leurs liens, a partir de rien. Alors que, si nous comptons une classe VolGenerique , 
les valeurs des attributs et les liens des vols partant de X ne sont pas perdus ; il n'y 
aura simplement pas d'instance de Vol reel correspondante pendant trois mois. 

Pour mettre a jour le modele, il suffit done de : 

• repartir les attributs, les operations et les associations de l'ancienne classe 
Vol entre les deux classes VolGenerique et Vol ; 

• ajouter une association « 1-* » decrit entre VolGenerique et Vol. 

Nous avons en outre ajoute deux attributs dans la classe VolGenerique pour indiquer 
le jour de la semaine du vol, et la periode de l'annee ou il est disponible. Une con- 
trainte supplementaire lie les valeurs des attributs dateDepart de la classe Vol et de 
la classe VolGenerique. 



A retenir PERIODEVALIDITE AVEC UN TYPE NON PRIMITIF 



L'attribut periodeValidite n'est pas un attribut simple. En effet, on peut 
lui demander son debut, sa fin, sa duree, etc. Une solution a ete 
proposee par M. Fowler b : creer une classe TimePeriod (comme pour 
Date precedemment), et I'utiliser ensuite pour typer l'attribut. 



TimePeriod 


1 i 

1 1 
end 


DateTi 


tieStamp 









Date 



Time 



b. Analysis Patterns: Reusable Object Models, M. Fowler, 1997, Addison-Wesley. 

Enfin, il faut veiller a bien respecter la phrase 2. Un vol est ouvert ou ferme a la 
reservation sur ordre de la compagnie. C'est bien le vol date, et pas le vol generique, 
qui est concerne. Meme chose pour une eventuelle annulation. . . II nous faut done 
ajouter une association directe entre Vol et Compagnie Aerienne, qui permette 
l'interaction decrite a la figure 3-10, tout en conservant l'association qualifiee entre 
VolGenerique et Compagnie Aerienne. 

La figure 3-32 est done transformed comme cela est montre sur le schema ci-apres. 
Chacune des deux classes - Vol et VolGenerique - a retrouve une forte cohesion. 
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A retenir PATTERN DE LA METACLASSE 

La separation des responsabilit.es operee precedemment peut se genera- 
liser sous la forme d'un « pattern d'analyse » reutilisable dans d'autres 
contextes et deja decrit par de nombreux auteurs. 

On identifie une classe AX qui 
possede trap de responsabi- 
lites, dont certaines ne sont 
pas propres a chaque instance. 
On ajoute une classe TypeXX, 
on repartit les propriet.es sur 
les deux classes et on les relie par une association «*- 1 ». La classe 
TypeXX est qualifiee de « metaclasse », comme VolGenerique sur la figure 
ci-dessus, car elle contient des informations qui decrivent la classe XX. 

Ce pattern serait par exemple utile pour modeliser les livres d'une biblio- 
theque. La classe Livre jouerait le role de TypeXX, avec des attributs 
comme date de parution, ISBN, nombre de pages, etc. La classe Exemplai- 
reLivre jouerait quant a elle le role de la classe XX, avec un attribut etat 
(neuf, moyen, abime), une association est emprunte par vers Adherent, 
etc. On parle d'ailleurs egalement de pattern « Type - Exemplaires ». 



XX 




TypeXX 


att1 
att2 


att3 
att4 


> 

1 







Etape 7 - Structuration en packages 



Notre modele statique d'analyse est maintenant presque finalise. Pour rendre son 
emploi plus aise encore et ann de preparer l'activite de conception objet, nous allons 
le structurer en packages. 
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A retenir STRUCTURATION EN PACKAGES 



La structuration d'un modele statique est une activite delicate. El le doit 
s'appuyer sur deux principes fondamentaux : coherence et independance. 

Le premier principe consiste a regrouper les classes proches d'un point 
de vue semantique. Pour cela, il faut que les criteres de coherence 
suivants soient reunis : 

- finalite : les classes doivent rendre des services de meme nature aux 
utilisateurs ; 

- evolution : on isole ainsi les classes reellement stables de celles qui vont 
vraisemblablement evoluer au cours du projet, ou meme par la suite. On 
distingue notamment les classes metier des classes applicatives ; 

- cycle de vie des objets : ce critere permet de distinguer les classes 
dont les objets ont des durees de vie tres differentes. 

Le second principe consiste a renforcer ce decoupage initial en s'effor- 
cant de minimiser les dependances entre les packages. 



Figure 3-34. 

Modele d'analyse 
avant structuration 
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EXERCICE 3-12. 

Decoupage en packages 

Proposez un decoupage du modele d'analyse en deux packages. 

D'apres les criteres precedents, nous pouvons proposer une premiere decoupe en 
"o deux packages : 

• le premier va concerner la definition des vols, tres stable dans le temps, sur- 
tout la partie specifique a VolGenerique ; 

• le second va traiter des reservations, avec toutes leurs associations. 

Chaque package contient bien un ensemble de classes fortement reliees, mais les 
classes des deux packages sont presque independantes. Cette premiere decoupe est 
materialisee par la ligne qui partage le schema presente ci-apres. 



Figure 3-35. 

Decoupe du modele en deux 
parties peu dependantes 
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II y a toutefois une autre solution qui consiste a positionner la classe Vol dans le 
meme package que la classe Reservation , comme cela est illustre sur le schema sui- 
vant. Le critere privilegie dans cette seconde decoupe est la duree de vie des objets, 
les vols instancies se rapprochant plus des reservations que des vols generiques. 
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EXERCICE 3-13. 

Reduction du couplage 



Trouvez une solution qui permette de minimiser le couplage entre les deux 
packages. 



Dans les deux cas precedents, nous pouvons constater qu'au morns une association 
O traverse la frontiere entre les packages. Le probleme que posent les associations qui 
vT* traversent deux packages reside en ceci qu'une seule d'entre elles suffit a induire 
une dependance mutuelle, si elle est bidirectionnelle. Or, le concepteur objet doit 
faire la chasse aux dependances mutuelles ou cycliques, arm d'augmenter la modu- 
larity et l'evolutivite de son application. 

Dans la premiere solution, une seule association est en cause, comme cela est rap- 
pele ci-apres. Mais, a elle toute seule, elle provoque une dependance mutuelle entre 
les deux packages. 



Figure 3-37. 

Dependance 
mutuelle entre les 
packages 




ouvrirReservation() 
fermerReservation() 



A retenir NAVIGABILITE ET DEPENDANCE 

Une association entre deux classes A et B permet par defaut de naviguer 
dans les deux sens entre des objets de la classe A et des objets de la classe B. 

Cependant, il est possible de limiter cette navigation a une seule des deux 
directions, pour eliminer une des deux dependances induites par I'associa- 
tion. UML nous permet de representer explicitement cette navigabilite en 
ajoutant sur I'association une fleche qui indique le seul sens possible. 



Dans notre exemple, nous allons faire un choix et privilegier un sens de navigation 
arm d'elimrner une des deux dependances. II est certain qu'une reservation ne va 
pas sans connaissance du vol qui est concerne, alors qu'un vol existe par lui-meme, 
independamment de toute reservation. 
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Le diagramme precedent peut done etre modifie de facon qu'il ne fasse apparaitre 
que la dependance du package Reservations vers le package Vols. 



Figure 3-38. 

Couplage minimise 
entre les packages 
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Examinons maintenant la seconde solution. Cette fois-ci, deux associations traver- 
sent les packages. Que pouvons-nous faire pour reduire les navigabilites de ces 
associations ? 

II est logique d'imposer un sens de navigabilite unique de Vol vers VolGenerique : 
un vol reel est decrit par un et un seul vol generique auquel il doit avoir acces, alors 
qu'un vol generique peut exister par lui-meme. 

Helas, pour la seconde association, nous savons deja que la navigabilite est obliga- 
toire de CompagnieAerienne vers Vol, a cause de la phrase 2, illustree par le dia- 
gramme de communication de la figure 3-10. 

Meme si nous enlevons la navigabilite de Vol vers CompagnieAerienne, nous nous 
retrouvons done avec deux associations navigables dans des sens differents. Cela 
sufnt a imposer une dependance mutuelle entre les packages, comme cela est repre- 
senteci-apres. 



Figure 3-39. 

Dependance mutuelle 
obligatoire pour la 
seconde solution 
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Cette etude sur le couplage des packages pour les deux solutions proposees fait 
done pencher la balance vers la premiere solution, ce qui n'etait pas du tout evident 
au depart. 

Le package Vols peut maintenant se preter a une reutilisation, contrairement au pac- 
kage Reservations. La repartition des classes entre les deux packages est represen- 
tee graphiquement sur la figure suivante. II s'agit d'un diagramme de packages, 
officialise par UML 2.0. 



Figure 3-40. 

Diagramme de packages 
de la solution retenue 



Reservations 

+ Client 
+ Passager 
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Vols 
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+ VolGenerique 



Etape 8 - Inversion des dependances 

Exercice 3-14. 
Inversion des dependances 



Pour des raisons d'organisation sur le projet, nous avons la contrainte 
suivante : le package Vols doit dependre du package Reservations, et non 
I'inverse. Proposez une modification minimale des diagrammes de classes pre- 
cedents permettant de se conformer a la contrainte 5 . 

<>° n 

L'inversion des dependances est un probleme classique de conception objet. On le 
~0 resout generalement en introduisant une classe abstraite (ou une interface) de la 
v5^ facon suivante. 



5. Un grand merci a Laurent Nonne, professeur a 1'IUT de Blagnac, qui m'a propose la solution du paragraphe lors d'un 
echange de courriers electroniques sur cet exercice. 
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A retenir INVERSION DE DEPENDANCE 

Supposons que nous ayons deux classes A et B relies par une associa- 
tion unidirectionnelle de A vers B. 

Ces deux classes appartiennent respectivement aux packages P1 et P2. 
II existe done une dependance de P1 vers P2. 



Figure 3-41. 

Exemple de dependance 
a inverser 




Nous souhaitons inverser les dependances entre P1 et P2 sans deplacer 
les classes A et B. 

Pour resoudre ce probleme, il suffit d'extraire une interface I que B 
implementera et de relier A a cette interface plutot qu'a B directement. 
L'interface I sera positionnee dans le meme package P1 que la classe A c . 
C'est maintenant le package P2 qui depend du package P1 ! 



Figure 3-42. 

Ajout d'une interface 
pour inverser la 
dependance 
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S'il n'est pas possible de positionner l'interface I dans le package PI , il faut alors creer un troisieme package P3 
dans lequel on placera I. Les packages PI et P2 dependent alors de ce nouveau package P3, mais n'ont plus de 
dependance entre eux. 

La solution est maintenant facile a realiser : ajouter une interface que la classe Vol va 
realiser et a laquelle la classe Reservation sera reliee. 
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Figure 3-43. 

Ajout d'une interface pour 
inverser la dependance 
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Pour la suite du chapitre, nous reviendrons cependant a la solution precedente, avec 
la dependance du package Reservations vers le package Vols, qui nous parait plus 
naturelle. 



L'etat complet de notre modele peut maintenant etre synthetase par la figure 3-44. 

Apres tout ce travail sur les reservations de vols, nous souhaitons elargir le champ du 
modele en proposant egalement des voyages en bus, que des transporteurs assurent. 

Un voyage en bus a une ville de depart et une ville d'arrivee, avec des dates et heures 
associees. Le trajet peut comporter des arrets dans des villes intermediaires. 

Un client peut reserver un ou plusieurs voyages, pour un ou plusieurs passagers. 
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Figure 3-44. 

Modele d'analyse complet 
de la reservation de vols 
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EXERCICE 3-15. 

Un modele du domaine similaire 



Par analogie avec la figure precedents proposez un modele du domaine de la 
reservation de voyages en bus. 



Le modele est quasiment la replique du precedent, y compris au niveau de la 
O decoupe en packages. 

II est un peu plus simple pour deux raisons : 



Point de vue statique 



DEUXIEME PARTIE 



II est un peu plus simple pour deux raisons : 

• la notion d'aeroport n'a pas d'equivalent, et la classe Ville est directement 
associee a la classe VoyageEnBus ; 

• la distinction entre Vol et VolGenerique ne semble pas transposable, car les 
voyages en bus ne sont pas aussi reguliers et ne sont pas definis a l'avance. 



Figure 3-45. 

Modele du domaine 
de la reservation de 
voyages en bus 
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EXERCICE 3-16. 

Optimisation de I'architecture logique 



II est clair que les diagrammes des figures 3-44 et 3-45 presenters de nombreuses 
similitudes : 

• certaines classes sont communes aux deux modeles : Ville, Client, Passager ; 

• certaines classes ont des points communs : ReservationBus et Reservation, 
InfosEscale et Infos Arret, etc . 

Nous allons done essayer de faire fusionner ces deux modeles en factorisant autant que 
faire se peut les concepts, afin de pouvoir encore elargir sa portee si necessaire (reserva- 
tion de croisieres, etc.). 

Proposez une architecture logique fusionnee qui soit la plus evolutive possible. 

O Deux taches principales doivent etre realisees : 

O * Isoler les classes communes dans de nouveaux packages, afin de pouvoir 
les reutiliser. 

• Factoriser les proprietes communes dans des classes abstraites. 

En premier lieu, commencons par l'identification et le regroupement des classes 
communes. 

La classe Ville est tres importante pour la description des vols et des voyages en bus. 
Dans le modele de la figure 3-45, nous avons en fait reutilise la classe Ville exis- 
tante, ce qui a immediatement cree une dependance non justifiee entre les packages 
VoyagesBus et Vols. Au lieu de proceder ainsi, il serait plus pertinent de l'isoler dans 
un package a part qui pourra etre reutilise a volonte, voire meme qui pourra etre 
achete dans le commerce, avec sa declinaison par pays. . . 

Afin que ce nouveau package soit vraiment un composant reutilisable, il ne faut pas 
qu'il depende des packages applicants qui contiennent les classes Aeroport et 
VoyagesBus. Pour ce faire, nous avons deja vu qu'il suffisait d'agir sur la navigabi- 
lite des associations concernees, comme cela est indique sur le schema ci-apres. 



Point de vue statique 



DEUXIEME PARTIE 



Figure 3-46. 

Isolation de la classe Ville 
dans un nouveau package 
reutilisable 



VoyagesBus 



VoyageEnBus 



dateDepart 
heureDepart 
dateArrivee 
heureArrivee 
/ duree 




Les classes Client et Passager sont egalement communes aux deux types de reser- 
vations. Nous aurons done interet a les isoler dans un nouveau package, comme 
cela a ete fait pour la classe Ville. Mais il ne serait pas judicieux de regrouper ces 
trois classes communes dans le meme package, simplement parce qu'elles sont 
communes. En effet, les concepts qu'elles represented n'ont pas de rapport. . . 

Apres cette premiere tache d'isolation des classes communes reutilisables, 
1' architecture logique se presente sous la forme du diagramme structurel suivant. 



Figure 3-47. 

Identification du 
package reutilisable 
Geographic 




ReservationsBus 



Package 
reutilisable 
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II nous faut maintenant factoriser les parties communes. 

Commencons par ce qui est le plus visible : la similitude entre les packages Reser- 
vationsVols et ReservationsBus saute aux yeux. La seule difference concerne les 
classes ReservationVol (appelee precedemment Reservation et renommee pour plus 
de clarte) et ReservationBus : elles ont les memes attributs et operations, et presque 
les memes associations. Une super-classe abstraite Reservation s'impose done en 
toute logique, comme cela est illustre sur le schema suivant. 



Figure 3-48. 

Introduction de la 
classe abstraite 
Reservation par 
generalisation 



Client 



nom 

prenom 

adresse 

numTel 

numFax 



a effectue 



1 

{frozen} 




Classe 
abstraite 



Passager 



nom 
prenom 



ReservationVol 
(from ReservationsVols) 



ReservationBus 

(from ReservationsBus) 



concerne 
1 



{frozen} 



Vol 

(from Vols) 



concerne 
1 



V 



{frozen} 



VoyageEnBus 
(from VoyagesBus) 



La classe abstraite Reservation ainsi que les deux classes Client et Passager, qui 
sont communes aux deux types de moyen de transport, sont isolees dans un nou- 
veau package appele Reservations. Ce package est appele package generalise en 
regard des deux packages ReservationsVols et ReservationsBus. En effet, les deux 
packages specialises heritent les classes de Reservations, et ont le droit d'en redefi- 
nir certaines. 

Le schema global des packages qui sont ainsi obtenus est represente sur la figure 
suivante. 
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Figure 3-49. 

Introduction du package 
generalise Reservations 




Geographie 




Package 
reutilisable 



Une solution plus sophistiquee, possible grace aux nouveautes UML 2, consiste a 
rendre le package Reservations generique (ou parametrable). La classe Reservation, 
qui redevient concrete, sert alors de parametre formel et sera remplacee par 
ReservationVol ou ReservationBus, suivant le cas. On parle ainsi de template 
package (Reservations) et de bound package (ReservationsBus et ReservationsVol). 
Remarquez la notation du parametre formel dans un rectangle pointille, ainsi 
que la generalisation avec le mot-cle « bind » et l'indication du remplace- 
ment du parametre formel par une classe dans les packages lies. 



Figure 3-50. 

Le package Reservations 
comme package generique 
( template package ) 



cd Template package 



Reservations 


1 Reservation 








h3 Passager 






B Reservation 







«bind» 

<Reservation > ReservationVol> 



ReservationsVol 

1 ReservationVol 



«bind» 

<Reservation > ReservationBus> 



ReservationsBus 

I ReservationBus 
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■ Agregation - composition ■ Generalisation 
- specialisation ■ Classe abstraite - classe 
concrete ■ Contrainte ■ Qualificatif ■ Pattern 

■ Classe structured - participant - role - 
connecteura Diagramme de structure composite 



Ce chapitre va nous permettre de completer au moyen de 
plusieurs petits exercices notre passage en revue des princi- 
pales difficultes que pose la construction des diagrammes de 
classes UML. 

Nous aborderons en particulier des sujets avances tels que : 

• la distinction entre agregation et composition ; 

• les limitations de la relation de composition ; 

• les classes structures UML 2 et le diagramme de struc- 
ture composite ; 

• la bonne utilisation de la generalisation et des classes 
abstraites ; 

• la bonne utilisation des classes d'association ; 

• les contraintes entre associations [xor, subset, etc.) ; 

• d'autres patterns d'analyse comme « Party* ou 
« Composite ». 
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Complements sur les relations entre classes 




EXERCICE 4-1. 

Relations structurelles entre classes 



Considerons les phrases suivantes : 

1 . Un repertoire contient des fichiers. 

2. Une piece contient des murs. 

3. Les modems et les claviers sont des peripheriques d'entree/sortie. 

4. Une transaction boursiere est un achat ou une vente. 

5. Un compte bancaire peut appartenir a une personne physique ou morale. 

6. Deux personnes peuvent etre mariees. 

Determinez la relation statique appropriee (generalisation, composition, agre- 
gation ou association) dans chaque phrase de I'enonce precedent. Dessinez le 
diagramme de classes correspondant. 

N'hesitez pas a proposer differentes solutions pour chaque phrase. 

O Les phrases 1 et 2 illustrent ce qui differencie 1' agregation de la composition : 
O 1. Un repertoire contient des fichiers. 
^ 2. Une piece contient des murs. 

« Un repertoire contient des fichiers » : il s'agit au moins d'une agregation. 
Voyons si nous pouvons aller plus loin et en faire une composition. Premier 
critere a verifier : la multiplicite ne doit pas etre superieure a un du cote du 
composite. C'est bien le cas dans la premiere phrase, puisqu'un fichier appar- 
tient a un et un seul repertoire. Second critere : le cycle de vie des parties doit 
dependre de celui du composite. La encore, c'est le cas, puisque la destruc- 
tion d'un repertoire entraine la destruction de tous les fichiers qu'il contient. 
Nous pouvons done parler de composition pour la premiere phrase. 

Procedons a la meme analyse pour la seconde phrase, « Une piece contient 
des murs ». Cette fois-ci, apres verification du premier critere, nous devons 
abandonner la composition. En effet, un mur peut appartenir a deux pieces 
contigues (voire plus). La relation n'est done qu'une agregation. Afin de com- 
pleter les multiplicites, nous considerons qu'une piece contient au moins un 
mur (circulaire !). 
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Figure 4-1. 

Diagramme de classes des 
phrases 1 et2 



Repertoire 



Fichier 



Composition 



Aggregation 




Les phrases 3 et 4 se modelisent en UML par des relations de generalisation : 

3. Les modems et les claviers sont des peripheriques d' entree/ sortie ; 

4. Une transaction boursiere est un achat ou une vente. 

La seule difference reside dans la formulation de la phrase 4 qui correspond a 
une specialisation, alors que celle de la phrase 3 est une generalisation. 
Cependant, nous pouvons apporter quelques precisions aux deux modeles : 

• Les super-classes sont abstraites : elles ne s'instancient pas directement, 
mais toujours par rintermediaire d'une de leurs sous-classes ; 

• L'arbre de generalisation de la phrase 3 est incomplet : il existe de nom- 
breux autres peripheriques d' entree/sortie, comme les ecrans, les souris, 
etc. 



Figure 4-2. 

Diagrammes de classes 
des phrases 3 et4 



G 

e 1 

n 
e 
r 
a 
1 
i 
s 
a 
t 
i 
o 
n 



Periphehque d'E/S 



Transaction boursiere 



{incomplete} 



Modem 



Clavier 



Achat 



Vente 



a 
t 
i 

f o 

n 



La phrase 5 n'est pas une simple generalisation : 

5. Un compte bancaire peut appartenir a une personne physique ou morale. 
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En effet, le groupe verbal employe n'est pas « est un » ou « est une sorte de », 
mais « appartient a ». II s'agit done d'une simple association. Une premiere 
approche simpliste consiste a decrire deux associations optionnelles, comme 
cela est illustre par la figure suivante. 



Figure 4-3. 

Diagramme de classes 
de la phrase 5 - 
Solution incorrecte 



appartient a 



CompteBancaire 




PersonnePhysique 



appartient a 



PersonneMorale 



Cette solution ne rend cependant pas compte du « ou exclusif » de la fin de la 
phrase. En effet, le diagramme precedent peut s'instancier aussi bien avec un 
objet CompteBancaire , lie a la fois a une PersonnePhysique et une Personne- 
Morale, qu'avec un CompteBancaire lie a aucun objet. Ce n'est pas ce que 
nous voulons : un objet CompteBancaire doit etre lie soit a une PersonnePhy- 
sique, soit a une PersonneMorale, pas aux deux a la fois, mais exactement a 
une des deux, a l'exclusion de l'autre. 

En fait, deux solutions correctes mais tres differentes sont possibles qui con- 
sistent a : 

• Introduire explicitement la contrainte predefinie {xor} entre les deux asso- 
ciations qui portent une multiplicite strictement egale a 1 ; 



Figure 4-4. 

Diagramme de classes 
de la phrase 5 - 
Premiere solution 



CompteBancaire 



appartient a 



appartient a 



PersonnePhysique 




PersonneMorale 



• Introduire une classe abstraite Personne, la specialisation jouant implicite- 
ment le role du « ou exclusif ». 
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CompteBancaire 


appartient a y 






0* I 1 





Figure 4-5. 

Diagramme de classes de la phrase 5 - 
Seconde solution 



















PersonneMorale 




PersonnePhysique 







Les deux solutions sont egalement valables en UML et correctes. Voila 
encore un bon exemple de ce que la modelisation n'est pas une science 
exacte, avec une solution unique pour un probleme donne. Le modelisateur a 
done le choix entre ces deux schemas. 

Un argument important en faveur de la seconde solution est que Ton peut fac- 
toriser des attributs (nom, adresse, etc.) et des operations (demenager, etc.) 
dans la classe abstraite. 



A retenir LE PATTERN « PARTY » 



Cette facon de modeliser des entires qui ont un nom et une adresse 
uniques (comme les personnes physiques ou morales) par une classe 
abstraite et deux sous-classes specialises a ete proposee par D. Hay a . 



Party 



name 
address 



Par exemple 
une societe 



Person 

socialSecurityNumber 
birthDate 




Organization" 



a. Data Model Patterns : Conventions of Thought, D. Hay, 1996, Dorset House Publishing. 



La phrase 6 presente la particularite de definir une relation entre objets de la 
meme classe. 



6. Deux personnes peuvent etre mariees. 
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Cela se traduit tout simplement par une association entre cette classe donnee 
et elle-meme. Les multiplicites du schema suivant sont deduites du droit fran- 
cais actuel : une personne n'est pas tenue d'etre mariee, mais ne peut pas etre 
mariee avec plusieurs personnes a la fois ! 



Figure 4-6. 

Diagramme de classes de la phrase 6 



est mariee a 



0..1 



Personne 


3 hysique 




0..1 





Association 
reflexive 



Si Ton veut ajouter la contrainte que le mariage ne peut unir que des person- 
nes de sexe oppose 1 , il y a la encore deux solutions : 

• Introduire explicitement un attribut enumere sexe : (h,f) et une contrainte 
sur 1' association ; 



Figure 4-7. 

Diagramme de classes complete de la phrase 6 



est mariee a 



c 



0.1 




PersonnePhysique 


► sexe : (h, f 


) 



0.1 



Contrainte 



{deux personnes de meme sexe 
ne peuvent pas etre mariees} 



Introduire deux sous-classes Homme et Femme comme sur la figure suivante. 



Figure 4-8. 

Version du diagramme de classes de 
la phrase 6 avec specialisation 



PersonnePhysique 



I 









Ho 


nme 


est marie a 


Ferr 


me 




0..1 0..1 









1 . Bien que cette contrainte soit de plus en plus abandonnee dans les pays europeens de nos jours. 
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Pour completer le modele, prenons en compte la nouvelle possibilite offerte 
par le PACS. Cela amene de nouveau une association reflexive, cette fois-ci 
non contrainte... 



Figure 4-9. 

Ajout du dispositif prevu par le Pacs 



est pacsee a 





0..1 




PersonnePhysique 








0..1 





I 



Homme 



est marie a 



0..1 



0..1 



Femme 



On notera toutefois qu'il faut en toute rigueur ajouter une contrainte qui inter- 
dise d'etre a la fois marie avec quelqu'un et « pacse » avec quelqu'un d'autre, 
ou « pacse » avec soi-meme. . . 

En outre, l'ajout de la date du mariage, du type de contrat, etc., illustre l'utili- 
sation de la classe d'association. Comme UML interdit a une classe disso- 
ciation d'avoir a la fois un nom sur l'association et un autre dans la classe, le 
schema devient alors : 



Figure 4-10. 

Version completee du diagramme de 
classes de la phrase 6 avec classes 
d'association 



{p.pacsee != p} . 



0..1 



PersonnePhysique 



nom 
prenom 



Contraintes 



Homme 



0..1 



0..1 



PACS 



~K /{xor} 



0..1 



Femme 



Mariage 



date 

contrat 

lieu 



Classes 
d' association 
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EXERCICE 4-2. 

Diagramme de classes : d'un modele simple, mais peu evolutif, a 
un modele souple, mais complexe... 

Proposez plusieurs solutions pour modeliser la phrase suivante : « un pays a 
une capitale. » 

Dessinez les diagrammes de classes correspondants et indiquez les avantages 
et inconvenients des differentes solutions. 



O Une phrase aussi simple que « un pays a une capitale » va nous permettre 
"o d'illustrer le caractere hautement subjectif de l'activite de modelisation, et le 
choix sou vent difficile qu'il faut operer entre simplicite et evolutivite. 

En effet, nous allons proposer pas moins de quatre solutions differentes a 
cette question, de la plus simple a la plus sophistiquee. . . 

Premiere solution, la plus compacte possible : une classe Pays avec un simple 
attribut capitale. C'est suffisant, si nous voulons seulement recuperer le nom 
de la capitale de chaque pays, et par exemple produire un petit tableau sur deux 
colonnes, avec les pays classes par ordre alphabetique. . . 



Figure 4-11. 

Solution compacte 



Pays 
capitale 



Difficile de faire plus simple ! Nous pourrons par la suite completer facile- 
ment le modele en ajoutant quelques attributs a la classe Pays : nom, langue, 
monnaie, etc. 

En revanche, comment faire si nous voulons ajouter des proprietes au concept 
de capitale : nombre d'habitants, superficie, etc. ? La solution precedents 
trouve la sa limite, et nous sommes alors obliges de promouvoir capitale au 
rang de classe. Nous retrouvons ici l'illustration de la difference entre classe 
et attribut, deja discutee lors de la question 3-2 du chapitre precedent. 



Solution « naturelle » 



Pays 


a 


Capitale 


nom 

langue 

monnaie 


nom 

nbHabitants 
superficie 


1 1 
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Pour poursuivre cette solution dite « naturelle », on peut se demander a juste 
titre si l'association n'est pas une agregation, voire une composition. En effet, 
un pays contient sa capitale et 1' agregation rappelle la contenance au sens car- 
tographique. Maintenant, peut-on aller plus loin et parler de composition ? 

Une capitale appartient bien a un pays et un seul, verifiant en cela le premier 
critere de la composition. Cependant, que se passe-t-il en cas de destruction 
d'un pays ? Si la capitale est egalement detruite, il s'agit bien d'une composi- 
tion ; dans le cas contraire, ce n'est qu'une agregation. Nous touchons la une 
difnculte venant de ce que la question ne mentionne aucun contexte qui nous 
permettrait de savoir comment ces concepts de pays et de capitale vont etre 
utilises. « Detruire » un pays peut aussi bien signifier le conquerir lors d'une 
guerre que l'enlever de la base de donnees de notre application informatique. . . 
Dans le second cas, la composition ne se discute pas, alors que dans le premier, 
c'est nettement moins clair. II faut un peu de reflexion pour comprendre que, la 
aussi, la capitale disparait en tant que concept administratif, meme si elle n'est 
pas detruite physiquement. Le schema se precise done comme il est indique 
sur la figure suivante. 



Figure 4-13. 

Solution « naturelle » afflnee 






Ville 


nom 

nb. Habitants 
superficie 


1 1 





En fait, nous sentons bien au fil des phrases qu'un concept plus general que 
capitale nous fait defaut : la notion de ville. Supposons qu'un pays soit 
annexe : sa capitale n'existe plus en tant qu'entite administrative, mais la ville 
elle-meme ne sera pas forcement detruite ! Done, si nous souhaitons definir 
un modele plus general, il est interessant de modeliser le fait qu'une capitale 
est une ville qui joue un role particulier au sein d'un pays. Une premiere solu- 
tion incomplete est donnee ci-apres. 



Figure 4-14. 


Pays 




Ville 


Introduction du concept de ville 


nom 


♦ 1 1 


nom 




langue 


nb. Habitants 




capitale 




monnaie 


superficie 











II serait dommage de ne pas profiter de 1' introduction du concept plus general 
de ville pour exprimer le fait qu'un pays contient des villes, dont une seule 
joue le role de capitale. Nous allons done ajouter une agregation multiple 
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entre Pays et Ville, et une contrainte pour exprimer le fait que la capitale d'un 
pays est forcement une de ses villes. Le modele devient maintenant nettement 
plus sophistique... 



Figure 4-15. 

Solution plus complete avec une contrainte 



Pays 


1..* 1.* 


Ville 


♦ A 

i 

{subset} 
1 ! 1 


nom 

langue 

monnaie 


nom 

nb. Habitants 
superficie 




capitale 





II faut noter que nous avons considere qu'une ville peut appartenir a plusieurs 
pays dans un souci de generalite, et pour nous premunir d'eventuelles 
remarques sur le statut particulier passe ou futur de villes telles que Berlin 
ou Jerusalem. . . Du coup, la relation ne peut etre qu'une agregation. 

Enfin, si nous voulons preciser qu'une capitale est une ville, mais qu'elle pos- 
sede des proprietes specifiques, il faut alors en faire une sous-classe et non un 
role, comme cela est montre sur le schema presente ci-apres. 



Figure 4-16. 

Solution avec super-classe concrete 




specialisation 



1..* 



Ville 



nom 
nb. Habitants 
superficie 




Capitale 



La classe Capitale peut maintenant recevoir des attributs ou associations sup- 
plementaires, si le besoin s'en fait sentir. Cependant, pour indiquer que la 
multiplicite 1 du cote Pays sur la composition avec Capitale remplace la mul- 
tiplicite moins contraignante « 1„* » du cote Pays pour les villes, il faudrait 
indiquer que la composition avec Capitale est une specialisation de 1' agrega- 
tion avec Ville. UML autorise effectivement la generalisation/specialisation 
entre associations. 
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Figure 4-17. 

Solution sophistiquee avec specialisations 




A retenir REDEFINITION DE PROPRIETE 



UML2 a introduit la notion de redefinition de propriete : attribut ou 
terminaison d'association. Parmi les caracteristiques susceptibles d'etre 
redefinies, on trouve le nom, le type (qu'on peut specialised, la valeur 
par defaut, I'etat de derivation, la visibility la multiplicite et les 
contraintes sur les valeurs. Le mot-cle redefines remplace ainsi le 
symbole de specialisation entre associations, peu implemente par les 
outilsdu marche (voir figure 4-18). 

Figure 4-18. 

Solution avec redefinition 
d'association (U ML 2.0) 



Pays 


^ lesvmes 


Ville 


1..* 1..* 


nom 
langue 
monnaie 


nom 

nbHabitants 
superficie 








laCapitale 
(redefines lesVilles} 



Comparez le modele ainsi obtenu avec celui de la figure 4-11. Les deux sont 
corrects, « legaux » en UML et expriment a leur facon la phrase initiale. Le 
premier est tres compact, simple a implementer, mais tres peu evolutif dans le 
cas ou il faudrait repondre a de nouvelles demandes d'un utilisateur. Le 
second est nettement plus complexe a implementer, mais tres souple ; il resis- 
tera longtemps a revolution des besoins utilisateurs. Le choix entre les deux 
solutions doit done se faire en fonction du contexte : faut-il privilegier la sim- 
plicity, les delais de realisation, ou au contraire la perennite et l'evolutivite ? 

II faut enfin noter que la super-classe Ville de la figure 4-18 n'est pas une 
classe abstraite. Cela est coherent puisqu'elle ne possede qu'une seule sous- 
classe. En effet, l'objectif d'une classe abstraite est de factoriser des proprietes 
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communes a plusieurs sous-classes, et non pas a une seule ! II est ainsi tout a 
fait possible qu'un modele complet contienne une specialisation unique, mais 
la super-classe ne doit alors pas etre abstraite. 

MODELISATION DU DOMAINE EN PRATIQUE 



EXERCICE 4-3. 

La modelisation du domaine en pratique 

Modelisez I'utilisation de feutres et de stylos... 
L'enonce est volontairement vague ! 



on 



o 



Un enonce aussi imprecis n'est pas rare au demarrage de projets reels... Nous 
allons cependant pouvoir construire sans difficulte un diagramme de classes perti- 
nent en utilisant notre connaissance usuelle de ces notions de feutres et de stylos. 

Nous commencons done par identifier deux classes : Feutre et Stylo, qui ont 
un certain nombre de proprietes communes (couleur, marque, etc.) mais qui 
comptent aussi des differences (considerons par exemple que les feutres ont 
un bouchon, alors que les stylos n'ont qu'une pointe retractable). Un modeli- 
sateur averti voit la immediatement la possibilite d'une relation de generalisa- 
tion/specialisation. II introduit done une classe abstraite pour factoriser les 
caracteristiques communes. 

Le modele peut deja ressembler au diagramme suivant : 

Figure 4-19. 

Premiere version du diagramme 
de classes 



Pen 



couleur 
marque 
niveauEncre 



ecrire() 



— classe 
abstraite 




classes 
specialisees 



Stylo *C 




Feutre 


rentrerPointe() 
sortirPointe() 


boucher() 
deboucher() 



0..1 

lo- 



ci 



Bouchon 



Prenez note des multiplicites entre Feutre et Bouchon : un feutre peut perdre 
son bouchon, et un bouchon le corps de son feutre d'origine. Cette notion de 
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Corps est interessante, et partagee par les stylos et les feutres. Par souci 
d'homogeneite avec Bouchon, nous l'ajoutons done. 



Figure 4-20. 

Deuxieme version du diagramme de classes 



I 



Pen 




Corps 


couleur 




poids 
tailie 

niveauEncre 


marque 




ecrireQ 


r ■ 







Stylo 



rentrerPointe() 
sortirPointeQ 
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La relation entre Pen et Corps est evidemment une composition. En revanche, il 
n'y a pas forcement coherence des cycles de vie entre Feutre et Bouchon, comme 
me le prouve tous les jours ma petite fille de 3 ans 2 ! Notez egalement que l'attri- 
but niveauEncre a ete deplace dans la classe Corps. Ce deplacement d'attribut 
d'une classe a l'autre est habituel surtout dans le cas de relations de composition 
ou d'agregation, afin que les classes soient plus homogenes et cohesives. 

Pour completer encore notre modele, introduisons le concept de feutre avec 
correcteur incorpore et surtout une classe pour modeliser l'utilisateur et/ou le 
proprietaire du Pen. 



utilisateurCourant 
0..1 
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Figure 4-21. 

Troisieme version du 
diagramme de classes 
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Deuxieme niveau de 
specialisation 




Remarquez l'utilisation judicieuse qui est faite des deux associations entre les 
classes Personne et Pen : on distingue ainsi avec precision, grace aux noms 



2. Pour dire vrai, au fil des nouvelles editions Noemie a grandi egalement. Elle a aujourd'hui 8 ans. mais elle egare encore 
regulierement ses bouchons de feutres . . . 



Point de vue statique 



DEUXIEME PARTIE 



des roles du cote Personne, les multiplicites qui sont totalement differentes 
dans les deux cas : 

• Une personne peut jouer le role de proprietaire par rapport a un nombre 
quelconque de pens, mais un pen n'a qu'un et un seul proprietaire. 

• Une personne peut utiliser au maximum un pen a la fois, et un pen peut 
avoir au maximum un utilisateur. 

La specialisation de Feutre en FeutreEffacable est remarquable pour les rai- 
sons suivantes : 

• Feutre n'est pas devenue une classe abstraite et ne possede qu'une seule 
specialisation. 

• La specialisation ne concerne que le comportement. 

• On doit done retenir qu'une super-classe n'est pas forcement abstraite 
(sinon on n'aurait pas besoin de l'aide visuelle du nom en italique comme 
pour Pen), et que la relation de generalisation/specialisation ne conduit pas 
toujours a un « arbre » d'heritage. 

A retenir LA CONTRAINTE {FROZEN} 

Cette contrainte standard en UML b permet d'ajouter une information 
detaillee, mais qui peut etre interessante, sur un diagramme de classes : 

- Pour un attribut, le fait que sa valeur ne change jamais pendant la vie 
d'un objet (parexemple, la marque d'un Pen). 

- Pour une association, le fait qu'un lien entre deux objets ne puisse plus 
jamais etre modifie apres sa creation (par exemple, le lien de composi- 
tion entre Pen et Corps, mais pas celui entre Feutre et Bouchon). 

Par defaut, les attributs et les associations ne sont pas {frozen}. 

Figure 4-22. 

Deuxieme 
version 
du modele 
avec les 
contraintes 
{ frozen} 



Stylo 

rentrerPointe() 
sortirPointe() 



b. En fait, la contrainte predefinie {frozen} semble avoir disparu des recents documents specifiant UML 2. Elle 
existait pourtant depuis UML 1.3, comme en atteste le UML User Guide de G. Booch. Du fait de son interet, 
nous preconisons de continue!' a l'utiliser, meme si elle ne fait plus partie du standard UML. 
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Dans le meme esprit, on aurait pu preciser que l'arbre d'heritage de Pen n'est pas 
complet (il y a certainement d'autres sortes de Pen que les stylos et les feutres) en lui 
adjoignant la contrainte predefinie {incomplete}. 



EXERCICE 4-4. 

La modelisation du domaine en pratique (suite) 

Proposez un cadre de modelisation des regies du jeu d'echecs. 

Attachez-vous d'abord au materiel utilise par les joueurs, puis a la notion de 
partie. 




on 



i SB a {3? Bag] 



O Commen9ons par interviewer un « expert metier » : le jeu d'echecs se joue a 
"o deux joueurs sur un echiquier carre compose de 64 cases, alternativement 
vT 1 noires et blanches. 



Figure 4-23. 

Modelisation d'un echiquier et de ses cases 



Echiquier 



matiere 
taille 



1 64 


Case 


couleur : (B, N) 
rangee : 1..8 
colonne : a..h 


♦ 





Chaque joueur possede initialement huit pions, ainsi qu'un roi, une dame, 
deux tours, deux fous et deux cavaliers. Par le biais de la promotion des pions 
en huitieme rangee (transformation obligatoire en piece a choisir sauf un roi), 
un joueur peut ainsi posseder jusqu'a neuf dames, dix tours, cavaliers ou fous 
et les multiplicites instantanees ne sont pas si evidentes ! 



Figure 4-24. 

Modelisation des pieces de chaque joueur 




II ne peut y avoir qu'une piece au maximum sur une case donnee. Les posi- 
tions initiales des pieces sont representees sur la figure precedente. 
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Figure 4-25. 

Modelisation des pieces et de leur position 
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L' introduction de la classe abstraite Piece est tout a fait naturelle. Tout 
d'abord, il s'agit bien d'un mot faisant partie du vocabulaire du domaine. 
Ensuite, cela permet d'exprimer le concept de position par un role unique de 
l'association entre les classes Piece et Case. Sur une case donnee, il ne peut 
pas y avoir plus d'une piece a la fois. Et une piece est soit sur une case, soit 
hors du jeu (prise). 

Les pieces ont chacune leur mode de deplacement propre. 



Figure 4-26. 

Modelisation du deplacement des pieces 
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couleur : (B, N) 
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ZT 
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Le deplacement des pieces est typiquement polymorphe. Chaque instance 
se deplace en fonction de l'algorithme declare au niveau des sous-classes 
concretes. 

En completant l'interview de notre expert metier, nous ajoutons quelques 
attributs et operations privees pour peaufiner la premiere partie du modele 
(voir figure 4-27) . 
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Figure 4-27. 

Modelisation de 
I'echiquier 
et des pieces 



Echiquier 



■ matiere 
■tale 



64 



Case 



couleur : (B, N) 
rangee : 1 ..8 
colon ne : a..h 



0..1 



0..1 



position 



Piece 



■ couleur : (B, N) 



7T 



Roi 

■ estEnEchec : boolean = false 

■ aBouge : boolean = false 



+ seDeplacer() 
- roquer() 



Dame 



+ seDeplacer() 



Tour 



+ seDeplacer() 
- roquer() 



Fou 
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A chaque tour, un joueur bouge une piece de son camp (blanc ou noir) . On ne 
peut ni passer son tour, ni jouer deux fois de suite. C'est toujours les blancs 
qui commencent la partie. Une partie est done une suite ordonnee de coups. 



Figure 4-28. 

Modelisation du deroulement de la partie 
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Si nous relions les concepts de coup, de piece et de case, nous obtenons la 
figure 4-29. 
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Figure 4-29. 

Modelisation detaillee 
du deroulement 
de la partie 
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- colonne : a..h 



Nous arretons la cette exploration du jeu d'echecs par le biais de la modelisa- 
tion statique, que nous pourrions encore detailler. 

Par ailleurs, si nous souhaitons ajouter d'autres regies plus dynamiques con- 
cernant par exemple la fin de la partie (cas de mat, pat, abandon, partie nulle, 
etc.), un diagramme d'etats est tout a fait approprie. Nous le presenterons au 
chapitre 6 (exercice 6-1). 



Les classes structures UML 2 




Exercice 4-5. 

Limitations de la relation de composition 



La figure 4-30 3 explique que les voitures et les bateaux possedent un moteur, 
que les voitures ont des roues alors que les bateaux ont des helices, et que les 
moteurs se decomposent tous de facon similaire. La composition exprime 
egalement le fait que la meme instance de Moteur ne peut pas appartenir 
simultanement a une instance de Voiture et une instance de Bateau, meme si 
la classe Moteur est partagee entre les classes Voiture et Bateau. C'est pour 



3. 



Cet exercice est inspire de l'excellent article de Conrad Bock intitule « UML 2 Composition Model » et publie dans le 
« Journal of Object Technology », Vol. 3, N° 10, November-December 2004. II est disponible sur le site web suivant : 
http://www.jot.fm/issues/issue_2004_l l/column5. 
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cela que les multiplicites concernees sont optionnelles (0..1) 4 . La composi- 
tion signifie encore qu'une instance de Moteur est detruite quand son instance 
conteneur de Voiture ou de Bateau est detruite. 



Figure 4-30. 

Utilisation de la 
composition UML 1 .x 



cd Composition UML 1.x 



z 



Vilebrequin 




Piston 













Figure 4-31. 

Exemple douteux 
d' associations 
au mime niveau 
de decomposition 



La relation de composition telle qu'elle existait dans UML 1.x fonctionne 
bien pour modeliser de la decomposition hierarchique. Cependant, elle pre- 
sente des limitations signiflcatives lorsqu'il s'agit de relier des elements au 
meme niveau de decomposition, comme tente sur le schema 4-31. 

cd Mauvais exemple y 





Roue 


actionne 


Moteur 


actionne 


Helice 








2 1 


1 1..4 



4. II aurait ete encore plus precis de laisser les multiplicites a 1 exactement, mais de poser une contrainte {xor} entre les 
deux compositions, comme sur la figure 4-4. 
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Expliquez pourquoi le diagramme precedent n'est pas satisfaisant et proposez une 
meilleure solution en utilisant le nouveau concept UML 2 de classe structures 

O Les associations ajoutees a la figure 4-3 1 par rapport a la 4-30 essaient 
"3 d'exprimer le fait que les moteurs actionnent des roues dans les voitures et 
vf* des helices dans les bateaux. Cependant, les associations sont definies globa- 

lement pour tous les moteurs, pas dans le contexte de voitures ou de bateaux 

particuliers. Cela signifie done que : 

• Le moteur d'une certaine voiture peut actionner les helices d'un bateau, ou 
les roues d'une autre instance de voiture. 

• Chaque moteur est cense actionner a la fois des roues et des helices. Si Ton 
avait mis une multiplicite 0..1 au lieu de 1 du cote Moteur, on aurait pu 
avoir cette fois-ci des moteurs n'actionnant rien du tout. 

• Un moteur peut actionner les deux roues gauches d'une voiture, au lieu des 
roues avant. L' association ne specifie pas quel couple de roues est actionne. 

Nous voyons done clairement que le modele propose n'est pas du tout satis- 
faisant. On pourrait dessiner un grand nombre de digrammes d'objets cohe- 
rents avec le diagramme de classes precedent, mais completement stupides ! 

UML 2 traite le probleme en introduisant un nouveau type de diagramme 
appele « diagramme de structure composite », avec les nouveaux concepts de 
classe structuree, participant et connecteur. 

A retenir CLASSE STRUCTUREE 

Une classe structuree est une classe dotee d'une structure interne. El le 
contient des participants (parts 0 ) reliees par des connecteurs. Une 
instance d'une classe structuree contient un objet ou un ensemble 
d'objets correspondant a chaque participant. Au sein de son conteneur, 
un participant possede un type et une multiplicite. Tous les objets d'un 
objet structure unique sont implicitement relies par le fait qu'ils sont 
contenus par le meme objet. 

CONNECTEUR 

Un connecteur est une relation contextuelle entre deux participants dans 
une classe structuree. La difference avec une association classique est la 
suivante : chaque association est independante des autres, alors que tous 
les connecteurs d'une classe structuree partagent un contexte unique. 

c. Le terme anglais part doit plutot etre traduit par participant que partie. II s'agit plus d'une notion de role joue 
par des elements types dans le contexte d'une classe que de contenance de definition. 
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Nous allons ainsi decrire deux contextes differents : celui de la classe Voiture 
et celui de la classe Bateau. A l'interieur de chaque contexte, les rectangles 
representent des participants avec pour chacune un nom de role et un type. Ces 
participants sont differents de simples instances car ils ne sont pas soulignes. 



Figure 4-32. 

Composition dans un contexte 
avec UML 2 



Cd Composition UML 2 



m : Moteur [1] 


actionne 


avant : Roue [2] 





arriere : Roue [2] 



m : Moteur [1] 


actionne 


h: Helice [1..4] 





La figure precedente exprime correctement que : 

• dans chaque voiture, il y aura un moteur, deux roues avant et deux roues arriere ; 

• le moteur actionne les roues avant situees dans la meme voiture que le moteur ; 

• ce moteur n'actionne rien d'autre dans la voiture, ni dans d'autres voitures 
ou dans des bateaux. 

Le meme raisonnement s'applique pour les bateaux. Un exemple de dia- 
gramme d'objets compatible est donne ci-apres. Notez le soulignement per- 
mettant de distinguer les instances par rapport aux participants. 



Figure 4-33. 

Diagramme d'objets UML 2 



monBateau :Bateau 
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EXERCICE 4-6. 

Description d'une chaTne HI-FI 



A retenir NOTION DE PORT 

Un port est un point d'interaction individuel entre une classe structured 
et son environnement. La classe (et ses ports) peut avoir des interfaces 
requises et fournies pour definir son comportement visible de I'exte- 
rieur. Lorsqu'on cree une instance de classe structured, ses ports sont 
crees avec elle. A sa destruction, ses ports sont detruits. On peut 
egalement connecter des ports a des participants internes ou a la 
specification de I'objet dans son ensemble. 



O Nous avons essaye de decrire, de maniere simplified mais realiste, un ampli- 
O tuner connectable a un lecteur DVD ainsi qu'a d'autres entrees possibles. Nous 
avons pour cela specifie les differents ports physiques presents sur ce type 
d'appareil, ainsi que l'interface homme-machine disponible sur la face avant de 
l'appareil 5 . Notez les symboles differents de l'interface fournie (lollipop) et de 
l'interface requise (socket) qui sont une nouveaute UML 2. Les interfaces sont 
definies en extension sur la droite du diagramme 4-34. 

Nous allons maintenant connecter les elements entre eux, sans oublier les 
enceintes, antennes, etc. Pour cela, nous allons utiliser le concept de collabo- 
ration avec sa definition UML 2. 



A retenir COLLABORATION 

Une collaboration decrit une relation contextuelle qui prend en charge 
I'interaction entre un jeu de participants. Un role est la description d'un 
participant. Contrairement a une classe structured, une collaboration ne 
detient pas les instances liees a ses roles. Ces dernieres existent avant 
I'etablissement d'une instance de la collaboration, mais la collaboration 
les rassemble et etablit des liens pour les connecter. 



5. II est clair que nous aurions pu utiliser aussi bien des composants que des classes structurees. La difference entre les 
deux n'est d'ailleurs pas significative en UML 2, le composant etant simplement de plus grosse granularite, mais con- 
ceptuellement equivalent (contrairement a la notion de composant UML 1 .x). 
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reglerVolumeQ : void 
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"interface" 
SelectionSource 



setTunerQ : void 
setDVDQ : void 
setAUXQ : void 
setTapeQ : void 



^interface" 
ReglageRadio 



presetBand() : void 
presetTuningQ : void 
memoryO : void 
autoManualQ : void 



"interface » 
ReglageHorloge 



+ displayQ : void 
+ hourAdjustQ : void 
+ minuteAdjustQ : void 





-•interface" 




LectureDVD 


+ 


standbyOnQ : void 


+ 


openCloseQ : void 


+ 


playPauseQ : void 


+ 


stopQ : void 


+ 


forwardQ : void 


+ 


backwardQ : void 



Figure 4-34. 

Elements de la chatne HI-FI 



La chaine HI-FI va etre ainsi vue comme une collaboration rassemblant un cer- 
tain nombre de participants dans un objectif commun, comme represente sur la 
figure suivante. Nous avons mixe volontairement les connecteurs simples et les 
connecteurs montrant l'imbrication des interfaces fournies et requises. 
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Figure 4-35. 

La chatne HI-FI vue comme une collaboration UML 2 

Qu'est-ce qu'un Home Cinema, sinon une chaine HI-FI connectee a un dispo- 
sitif de projection (abstraction pour television, videoprojecteur, etc.) ? Nous 
pouvons le representer par une nouvelle collaboration faisant intervener plus 
de participants de type Enceinte, et un participant supplemental de type 
Dispositif Pro jection . 
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cd Home Cinema 



z 
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Figure 4-36. 

Le « Home Cinema » vu comme 
une collaboration UML 2 



DECOUVERTE D'UN « PATTERN » 




EXERCICE 4-7. 

Decouverte guidee du pattern « Composite » 



Proposez une solution elegante qui permette de modeliser le systeme de ges- 
tion de fichiers suivant : 

1. les fichiers, les raccourcis et les repertoires sont contenus dans des repertoires 
et possedent un nom ; 

2. un raccourci peut concerner un fichier ou un repertoire ; 

3. au sein d'un repertoire donne, un nom ne peut identifier qu'un seul ele- 
ment (fichier, sous-repertoire ou raccourci). 

^5 Commengons par modeliser les trois phrases, une a une. 
O 1- Les fichiers, les raccourcis et les repertoires sont contenus dans des 
repertoires et possedent un nom. 
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Chacun des trois concepts doit etre represente par une classe. La contenance 
est modelisee par une composition, car la multiplicite du cote contenant est 
egale a 1 , et la destruction d'un repertoire entraine la destruction de tout ce 
qu'il contient. 



Figure 4-37. 

Modelisation de la phrase 1 



0..* 



Repertoire 



Raccourci 




Fichier 
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Deux associations en exclusion mutuelle traduisent parfaitement la deuxieme 
phrase : 

2. Un raccourci peut concerner un fichier ou un repertoire. 



Figure 4-38. 

Modelisation de la phrase 2 



Raccourci 



nom 



1 




Repertoire 



Fichier 



Les choses se compliquent quand il s'agit de modeliser la troisieme phrase : 
3. Au sein d'un repertoire donne, un nom ne peut identifier qu'un seul ele- 
ment (fichier, sous-repertoire ou raccourci). 

La solution la plus evidente consiste a qualifier chacune des trois composi- 
tions avec l'attribut nom. Ce qualificatif represente en fait le nom relatif de 
chaque element dans son repertoire englobant. On notera la reduction de la 
multiplicite de 1' autre cote du qualificatif. Pour modeliser le nom absolu, un 
attribut derive est tout a fait approprie, puisqu'il peut se deduire de la succes- 
sion des noms relatif s. 
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Figure 4-39. 

Modelisation de la phrase 3 




Qualif icatif s 
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Que pensez-vous du diagramme suivant, regroupant les modeles des trois phrases ? 



Figure 4-40. 

Premiere version du modele 



/ nomAbsolu 



Repertoire 



0..1 



nom 



0..1 



Raccourci 
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{xor} 
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Fichier 
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Le modele obtenu semble bien repondre aux trois phrases de l'enonce. Pour- 
tant, il n'est pas tout a fait correct ! En effet, d'apres la figure precedente, 
deux fichiers ou deux raccourcis ne peuvent pas avoir le meme nom au sein 
d'un meme repertoire, mais rien n'empeche en revanche qu'un fichier et un 
raccourci aient le meme nom. . . 

Ce leger defaut met en fait en evidence un probleme majeur : il nous faut un 
qualificatif unique pour tout type d'element contenu dans un repertoire et non 
pas un qualificatif pour chacun. Or, nous comptons trois compositions : il faut 
done modifier le modele en profondeur afin de n'avoir plus qu'une composi- 
tion a qualifier. Comment faire ? 
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La solution est en fait contenue dans la formulation de la troisieme phrase : 

« Au sein d'un repertoire donne, un nom ne peut identifier qu'un seul element 
(fichier, sous-repertoire ou raccourci). » 

Le mot « element » doit nous permettre de trouver l'idee salvatrice... Que 
contiennent les repertoires ? Des fichiers, des raccourcis et d'autres repertoi- 
res. Oui, mais encore, comment pouvons-nous tous les appeler ? Des 
elements ! Si nous ajoutons une super-classe abstraite Element generalisant 
les fichiers, les raccourcis et les repertoires, les trois compositions se resol- 
vent en une seule, avec un qualificatif unique, et le tour est joue ! Voici le 
modele que Ton obtient alors : 



Figure 4-41. 

Version finale elegante 



0.1 



Element 



I nomAbsolu 



7T 



Sous-classe 
composite de sa 
super-classe 
abstraite 




Ce qui est etonnant dans cette solution, et qui explique qu'elle ne soit pas si 
facile a trouver, c'est la double relation asymetrique entre les classes Repertoire 
et Element : 

• Repertoire est un composite par rapport a Element. 

• Repertoire est une sous-classe & Element. 
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A retenir LE PATTERN « COMPOSITE » 



La solution de la figure suivante a ete decrite d'une facon plus generale 
dans I'ouvrage de reference sur les Design Patterns^, sous le nom de 
pattern « composite ». 



Ce pattern fournit une solution 
elegante pour modeliser des 
structures arborescentes qui 
representent des hierarchies 
composant/compose. Le client 
peut ainsi traiter de la meme 
facon les objets individuels 
(feuilles) et leurs combinaisons 
(composites). 



Element 



1 











Noeud 




Feuille 



Figure 4-42. 

Pattern du composite sous forme simple 



d. Design Patterns: Elements of Reusable Object-Oriented Software, E. Gamma et cd., 1995, Addison- Wesley. 

Une autre facon d'utiliser un design pattern consiste a le representer comme une 
collaboration nominee, reliee aux classes qui jouent des roles dans la collabora- 
tion. Chaque dependance avec le mot-cle « role bindings est nommee par 
le role generique des classes dans le design pattern. II s'agit d'une maniere tres 
pratique d'appliquer un design pattern dans un contexte concret sans pour autant 
expliciter toutes les relations induites entre les classes qui collaborent. 



Figure 4-43. 
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I Point de vue statique 

I DEUXIEME PARTIE 

CONSEILS METHODOLOGIQUES 



NOTION D'ETAT ET DIAGRAMME DE CLASSES 

La notion d'etat ne doit pas apparaitre directement en tant qu'attribut sur les diagrammes 
de classes : elle sera modelisee dans le point de vue dynamique au moyen du diagramme 
d'etats. Dans le diagramme de classes UML, les seuls concepts dynamiques disponibles 
sont les operations. 

COMMENT POSITIONNER LES OPERATIONS ? 

En oriente objet, on considere que l'objet sur lequel on pourra realiser un traitement doit 
l'avoir declare en tant qu'operation. Les autres objets qui possederont une reference sur 
cet objet pourront alors lui envoyer un message invoquant l'operation. 

OBJET OU ATTRIBUT ? 

Un objet est un element plus « important » qu'un attribut. Un bon critere a appliquer 
peut s'enoncer de la facon suivante : si Ton ne peut demander a un element que sa 
valeur, il s'agit d'un simple attribut ; si Ton peut lui poser plusieurs questions, il s'agit 
plutot d'un objet qui possede a son tour plusieurs attributs, ainsi que des liens avec 
d' autres objets. 

A QUOI SERT LE DIAGRAMME D'OBJETS ? 

N'hesitez pas a utiliser le diagramme d'objets pour donner un exemple, ou encore un 
contre-exemple, qui permette d'affiner un aspect delicat d'un diagramme de classes. 

BONNE UTILISATION DE LA GENERALISATION 

N'employez la relation de generalisation que lorsque la sous-classe est conforme a 
100 % aux specifications de sa super-classe. 

SUPER-CLASSE ABSTRAITE OU CONCRETE ? 

Comprenez bien pourquoi une super-classe n'est pas toujours abstraite (sinon on 
n'aurait pas besoin de l'aide visuelle du nom en italique), et pourquoi la relation de 
generalisation/specialisation ne conduit pas toujours a un « arbre » d'heritage. 
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CONVENTIONS DE NOMMAGE UML 

• Les noms des attributs commencent toujours par une minuscule (contrairement aux 
noms des classes qui commencent systematiquement par une majuscule) et peuvent 
contenir ensuite plusieurs mots concatenes commen9ant par une majuscule. 

• II est preferable de ne pas utiliser d' accents ni de caracteres speciaux. 

• Les memes conventions s'appliquent au nommage des roles des associations, ainsi 
qu'aux operations. 

ATTRIBUT DERIVE ET QUALIFICATIF 

• Utilisez le concept d'attribut derive pour distinguer les attributs interessants pour 
l'analyste, mais redondants car leur valeur peut etre deduite a partir d'autres infor- 
mations disponibles dans le modele. Les attributs derives permettent a l'analyste 
de ne pas faire un choix de conception premature. 

• Utilisez a bon escient les qualificatifs, sans oublier la modification de la multipli- 
cite de l'autre cote de l'association. 

AG REG ATI ON OU COMPOSITION ? 

Pour qu'une agregation soit une composition, il faut verifier les deux criteres suivants : 

• La multiplicite ne doit pas etre superieure a un du cote du composite. 

• Le cycle de vie des parties doit dependre de celui du composite (en particulier 
pour la destruction) . 

LIMITATIONS DE LA COMPOSITION 

La relation de composition telle qu'elle existait dans UML 1.x fonctionne bien pour 
modeliser de la decomposition hierarchique. Cependant, elle presente des limitations 
significatives lorsqu'il s'agit de relier des elements au meme niveau de decomposition. 
En effet, les associations sont definies globalement, pas dans le contexte de classes et 
encore moins d'instances particulieres 

Si necessaire, vous devez avoir recours au puissant diagramme de structure composite. 
Celui-ci introduit les nouveaux concepts de classe structuree, participant (pari) et 
connecteur. Une classe structuree est une classe dotee d'une structure interne. Elle 
contient des participants relies par des connecteurs. Une instance d'une classe structuree 
contient un objet ou un ensemble d'objets correspondant a chaque participant. Au sein de 
son conteneur, un participant possede un type et une multiplicite. Tous les objets d'un 
objet structure unique sont implicitement relies par le fait qu'ils sont contenus par le 
meme objet. Un connecteur est une relation contextuelle entre deux participants dans une 
classe structuree. La difference avec une association classique est la suivante : chaque 
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association est independante des autres, alors que tous les connecteurs d'une classe struc- 
turee partagent un contexte unique. 

LA STRUCTU RATION DU MODELE STATIQUE 

• La structuration d'un modele statique est une activite delicate. Elle doit s'appuyer 
sur deux principes fondamentaux : coherence et independance . Le premier principe 
consiste a regrouper les classes qui sont proches d'un point de vue semantique. 
A cet egard, il faut chercher l'homogeneite au niveau des criteres suivants : flnalite, 
evolution et cycle de vie. Le second principe consiste quant a lui a renforcer ce 
decoupage initial en s'efforcant de minimiser les dependances entre les packages. 

• Le probleme des associations qui traversent deux packages reside dans le fait 
qu'une seule d'entre elles suffit a induire une dependance mutuelle, si elle est 
bidirectionnelle. II est toutefois possible de limiter cette navigation a une seule des 
deux directions, pour eliminer une des deux dependances induites par 1' associa- 
tion. UML nous permet de representer explicitement cette navigabilite en ajoutant 
sur l'association une Heche qui indique le seul sens possible. 

• Pour qu'un package soit vraiment un composant reutilisable, il ne faut pas qu'il 
depende des autres packages. 

• Respectez les sacro-saints principes des dependances entre packages : 

- Pas de dependances mutuelles. 

- Pas de dependances circulates. 

- Un package d'analyse contient generalement moins de 10 classes. 

LA SUBJECTIVITE DE LA MODELISATION 

Soyez conscient du caractere hautement subjectif de l'activite de modelisation, et du 
choix souvent difficile qu'il faut faire entre simplicite et evolutivite. Un modele tres 
compact, simple a implementer, sera peu evolutif lorsque de nouvelles demandes 
emaneront des utilisateurs. Un modele nettement plus complexe a implementer, mais 
tres souple, resistera mieux a revolution des besoins utilisateurs. Le choix entre les deux 
solutions doit done se faire en fonction du contexte : faut-il privilegier la simplicite, les 
delais de realisation, ou au contraire la perennite et l'evolutivite ? 

FORTE COHESION ET METACLASSE 

• Veillez a ce que vos classes n'aient pas trop de responsabilites differentes, sous 
peine de violer un principe fort de la conception orientee objet, appele forte 
cohesion. 

• Si vous identifiez une classe XX qui possede trop de responsabilites, et dont cer- 
taines ne sont pas propres a chaque instance, pensez au pattern de la metaclasse. 
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Ajoutez une classe TypeXX, repartissez les proprietes sur les deux classes et 
reliez-les par une association « * - 1 ». La classe TypeXX est qualifiee de 
« metaclasse », car elle contient des informations qui decrivent la classe XX. On 
parle aussi de type et d'exemplaires. 

ETUDIEZ LES PATTERNS ! 

Apprenez a identifier les moments opportuns ou il convient d'utiliser un pattern de 
modelisation. Contraignez-vous a les etudier serieusement afin de ne pas « reinventer la 
roue » a chaque nouveau modele ! 




Chapitre 



5 



Moderation dynamique : 

etude de cas 



4-1 

O 
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■ Acteur ■ Cas d'utilisation, scenario ■ Diagramme 
de sequence systeme ■ Diagramme de contexte 
dynamique ■ Message ■ Diagramme d'etats ■ Etat, 
transition ■ Evenement ■ Condition ■ Action - Activite. 



Ce chapitre va nous permettre d'illustrer pas a pas, a partir 
d'une nouvelle etude de cas, les principaux concepts et dia- 
grammes UML pour le point de vue dynamique. 

En commencant par identifier les acteurs et les cas d'utilisation, 
nous dessinerons tout d'abord un diagramme de sequence 
« systeme ». Puis, nous realiserons un diagramme de communi- 
cation particulier (que nous appellerons diagramme de contexte 
dynamique) afin de repertorier tous les messages que les 
acteurs peuvent envoyer au systeme et recevoir. 

Apres ce travail preliminaire, nous nous embarquerons dans 
une description en profondeur de la dynamique souhaitee du 
systeme. Nous insisterons tout particulierement sur le dia- 
gramme d'etats qui est a notre avis trop souvent sous- 
employe, alors que c'est un diagramme extremement utile 
pour decrire avec precision des comportements complexes, 
et ce des I'analyse. 



I Point de vue dynamique 

I TROISIEME PARTIE 

En complement des concepts de base, nous expliquerons la 
bonne utilisation des concepts avances tels que : 

• Evenement interne : when 

• Etat composite et sous-etats exclusifs 

• Transition propre et transition interne 

• Pseudo-etat : History 

• Envoi de message : send 

Principes et definitions de base 



DIAGRAMME D'ETATS 

UML a repris le concept bien connu de machine a etats finis, qui consiste a s'interesser 
au cycle de vie d'une instance generique d'une classe particuliere au fil de ses interac- 
tions avec le reste du monde, dans tous les cas possibles. Cette vue locale d'un objet, qui 
decrit comment il reagit a des evenements en fonction de son etat courant et comment il 
passe dans un nouvel etat, est representee graphiquement sous la forme d'un diagramme 
d' etats 1 . 

Un diagramme d'etats pour quelles classes ? 

Toutes les classes du modele statique ne requierent pas necessairement une machine a 
etats, representee par un diagramme d'etats. II s'agit done de trouver celles qui ont un 
comportement dynamique complexe necessitant une description poussee. Cela corres- 
pond a l'un des deux cas suivants : 

• les objets de la classe peuvent-ils reagir differemment a 1' occurrence du meme 
evenement ? Chaque type de reaction caracterise un etat particulier ; 

• la classe doit-elle organiser certaines operations dans un ordre precis ? Dans ce 
cas, des etats sequentiels permettent de preciser la chronologie forcee des evene- 
ments d' activation. 

Comment le construire ? 

1. Representez tout d'abord la sequence d'etats qui decrit le comportement nominal 
d'un objet, avec les transitions qui y sont associees. 

2. Ajoutez progressivement les transitions qui correspondent aux comportements alter- 
natifs ou d'erreur. 



1. UML utilise beaucoup le terme statechart, issu des travaux de D. Harel (voir www.ilogix.com). 
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3. Completez les effets sur les transitions et les activites dans les etats. 

4. Structurez le diagramme en sous-etats s'il devient trop complexe. 

Comment le representor ? 

Un diagramme d'etats est un graphe oriente d'etats et de transitions. 



Figure 5-1. 

Notation de base du 
diagramme d'etats 




Un etat represente une situation durant la vie d'un objet pendant laquelle : 

• il satisfait une certaine condition ; 

• il execute une certaine activite ; 

• ou bien il attend un certain evenement. 

Un objet passe par une succession d'etats durant son existence. Un etat a une duree nnie, 
variable selon la vie de 1' objet, en particulier en fonction des evenements qui lui arrivent. 

Comment les identifier ? 

Comment trouver les etats d'une classe ? Pour faire un parallele, on peut dire qu'il est 
aussi difficile de trouver les bons etats dans le modele dynamique que les bonnes classes 
dans le modele statique ! II n'y a done pas de recette miracle, cependant trois demarches 
complementaires peuvent etre mises en ceuvre : 

• la recherche intuitive repose sur 1' expertise metier. Certains etats fondamentaux 
font partie du vocabulaire des experts du domaine et sont identifiables a priori ; 

• 1' etude des attributs et des associations de la classe peut donner des indications 
precieuses : cherchez des valeurs seuils d'attributs qui modifient la dynamique, ou 
des comportements qui sont induits par l'existence ou l'absence de certains liens ; 

• une demarche systematique peut egalement etre utilisee : classe par classe, cherchez 
le diagramme d'interaction le plus representatif du comportement des instances de 
cette classe, associez un etat a chaque intervalle entre evenements emis ou recus par 
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une instance et placez les transitions. Reproduisez ensuite cette demarche avec tous 
les scenarios faisant intervenir des instances de la classe, afin d'ajouter de nouvelles 
transitions ou de nouveaux etats. La difficulte principale consiste a trouver ensuite 
les boucles dans le diagramme, afin de ne pas multiplier les etats. 

Etat initial et etat final 

En plus de la succession d'etats « normaux » correspondant au cycle de vie d'un objet, 
le diagramme d'etats comprend egalement deux pseudo-etats : 

• L'etat initial du diagramme d'etats correspond a la creation de l'instance. 

• L'etat final du diagramme d'etats correspond a la destruction de l'instance. 

TRANSITION 

Une transition decrit la reaction d'un objet lorsqu'un evenement se produit (generale- 
ment l'objet change d'etat). En regie generale, une transition possede un evenement 
declencheur, une condition de garde, un effet et un etat cible. 

EVENEMENT 

En UML, un evenement specifie qu'il s'est passe quelque chose de significatif, localise 
dans le temps et dans l'espace. Dans le contexte des machines a etats finis, il represente 
l'occurrence d'un stimulus qui peut declencher une transition entre etats. 

UML propose de distinguer quatre sortes d'evenements : 

• la reception d'un message envoye par un autre objet, ou par un acteur. L'envoi 
d'un message est en general asynchrone ; 

• I'appel d'une operation {call event) sur l'objet recepteur. L'evenement d'appel est 
en general synchrone ; 

• le passage du temps (time event), qui se modelise en utilisant le mot-cle after 
suivi d'une expression representant une duree, decomptee a partir de l'entree dans 
l'etat courant ; 

• un changement dans la satisfaction d'une condition (change event). On utilise 
alors le mot-cle when, suivi d'une expression booleenne. L'evenement de chan- 
gement se produit lorsque la condition passe a vrai. 

Un evenement peut porter des parametres qui materialised le flot d'informations ou de 
donnees entre objets. 

MESSAGE 

Un message est une transmission d'information unidirectionnelle entre deux objets, 
l'objet emetteur et l'objet recepteur. 
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Le mode de communication peut etre synchrone ou asynchrone. La reception d'un 
message est un evenement qui est doit etre traite par le recepteur. 



CONDITION 

Une condition (ou condition de garde) est une expression booleenne qui doit etre vraie 
lorsque l'evenement arrive pour que la transition soit declenchee. Elle peut concerner les 
attributs de l'objet ainsi que les parametres de l'evenement declencheur. Plusieurs transi- 
tions avec le meme evenement doivent avoir des conditions de garde differentes. 



Comment representer les concepts dynamiques de base ? 




EFFET : ACTION OU ACTIVITE 

Une transition peut specifier un comportement optionnel realise par l'objet lorsque la 
transition est declenchee. Ce comportement est appele « effet » en UML 2 : cela peut 
etre une simple action ou une sequence d' actions (une activite). Une action elementaire 2 
peut representer la mise a jour d'un attribut, un appel d'operation, la creation ou la 
destruction d'un autre objet, ainsi que l'envoi d'un signal a un autre objet. Les activites 
associees aux transitions sont considerees comme atomiques, c'est-a-dire qu'elles ne 
peuvent etre interrompues. Ce sont typiquement des sequences d'actions. 

2. UML 2 a apporte la definition de plus de cinquante actions elementaires avec leur nom et leur semantique. 



Point de vue dynamique 



TROISIEME PARTIE 



Les activites durables (do-activity), au contraire, ont une certaine duree, sont inter- 
ruptibles et sont done associees aux etats. 

COMMENT REPRESENTER LES DIAGRAMMES D'ETATS ? 



Figure 5-3. 

Notation plus complete 
du diagramme d 'etats 



Etat initial 
de I'objet 
(creation) 




Etat 1 



do /activite 1 



evenement (parametres ) [ condition ] / effet 



Etat avec 
activite durable 



Transition avec 
condition et effet 



Etat 2 



it final H 
I'objet ) 



Etat 
de 

(destruction) 



V 

m 



Etude d'un Publiphone a pieces 



Cette etude de cas concerne un systeme simplifie 
de Publiphone a pieces. 

1. Le prix minimal d'une communication inter- 
urbaine est de 02 euros. 

2. Apres l'introduction de la monnaie, l'utilisa- 
teur a 2 minutes pour composer son numero 
(ce delai est decompte par le standard 3 ). 

3. La ligne peut etre libre ou occupee. 

4. Le correspondant peut raccrocher le premier. 

5. Le Publiphone consomme de l'argent des que l'appele decroche et a chaque unite de 
temps (UT) generee par le standard. 

6. On peut ajouter des pieces a tout moment. 

7. Lors du raccrochage, le solde de monnaie est rendu. 

A partir de ces six phrases, nous allons progressivement : 
1 . Identifier les acteurs et les cas d'utilisation. 




3. Nous utilisons le terme « standard », mais il represente en fait le reseau telephonique dans son ensemble. 
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2. Construire un diagramme de sequence systeme. 

3. Construire le diagramme de contexte dynamique. 

4. Elaborer le diagramme d'etats du Publiphone. 



Etape 1 - Identification des acteurs et des cas d'utilisation 



En premier lieu, nous allons identifier les acteurs et les cas d'utilisation du Publiphone a 
pieces. 

EXERCICE 5-1. 

Diagramme de cas d'utilisation 

Dessinez le diagramme de cas d'utilisation du Publiphone a pieces. 



O Queries sont les entites externes qui interagissent directement avec le 
"o Publiphone ? 

Si nous procedons a une analyse linguistique de l'enonce, nous obtenons les cinq 
candidats suivants : utilisateur, standard, correspondant, Publiphone, appele. 

Eliminons tout de suite Publiphone puisqu'il s'agit du systeme lui-meme. En 
revanche, le standard est bien un acteur (non-humain) connecte directement 
au systeme. 

La seule difficulte concerne les acteurs humains : utilisateur, correspondant et 
appele. Comme les deux derniers termes semblent etre synonymes, nous pouvons 
garder le mot appele et renommer, par souci de symetrie, utilisateur en appelant. 



Figure 5-4. 

Liste preliminaire des acteurs 



Appelant 



«actor» 
Standard 



Appele 



Comment les acteurs utilisent-ils le Publiphone ? La seule utilisation vrai- 
ment interessante dans notre contexte est celle de 1' appelant qui telephone a 
l'appele. Le standard sert en fait d'intermediaire entre les deux. Si nous affi- 
nons encore notre analyse, nous nous apercevons rapidement que l'appele 
n'interagit pas directement avec le Publiphone : il est completement masque 
par le standard. 
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Une illustration graphique de ce probleme de determination de frontiere est 
donnee sur le diagramme de contexte statique suivant. 




On voit bien sur le diagramme precedent que 1' appelant communique avec 
l'appele par le biais de trois systemes connectes : le Publiphone, le standard et le 
telephone de l'appele. On notera la symetrie du schema en regard du standard, qui 
joue le role d'acteur par rapport aux deux autres systemes de meme nature. 

L'appele est done un acteur indirect par rapport au Publiphone. Nous ne le retien- 
drons pas pour notre diagramme de cas d'utilisation qui est finalement tres simple. 



Figure 5-6. 

Diagramme de cas 
d'utilisation 
du Publiphone 



Appelant 





Publiphone 






«actor» 
Standard 


t 


Telephoner 







Etape 2 - Realisation du diagramme de sequence systeme 



Avant de plonger dans les arcanes du diagramme d'etats du Publiphone, nous allons le 
preparer en realisant tout d'abord un diagramme de sequence systeme. Nous avons vu aux 
chapitres 1 et 2 l'interet de ce type de diagramme et les differents details qui le concernent. 
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EXERCICE 5-2. 

Diagramme de sequence systeme 

Realisez un diagramme de sequence systeme qui decrive le scenario nominal 
du cas d'utilisation Telephoner. 



J- 

O 



on 

En se basant sur notre connaissance du domaine, nous allons decrire le scena- 
rio nominal de succes de communication entre un appelant et un appele. 

Comme cela est explique aux chapitres 1 et 2, nous utilisons la convention 
graphique suivante : 

• l'acteur principal Appelant a gauche ; 

• une ligne de vie representant le Publiphone au milieu ; 

• l'acteur secondaire Standard a droite. 

Notez l'utilisation de deux fragments UML 2 : 

• loop pour indiquer l'iteration sur la phase de conversation avec le trans- 
port de la voix et le passage des unites de temps (UT) ; 

• opt pour indiquer la possibilite d'ajouter des pieces pendant la conversation. 



Figure 5-7. 

Diagramme de sequence 
systeme du scenario 
nominal de Telephoner 



: Appelant 



: Publiphone 



loop 
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decrocher Combine 



introPiece (0,2 €) 



composer Numero (0562475200) J acneminerNum e ro (0562475200) 



voix appele 



opt J* 


introPiece (0,2 €) 










raccrocher Combine 









^1 


k 


tonalite (libre) 












debuter Comm 








voix appele 






voix appelant 




^ — 


UT 
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Nous n'avons pas represente pour l'instant les reponses du Publiphone a l'appelant (en 
termes de tonalite par exemple) afin de ne pas alourdir ce premier schema. 




EXERCICE 5-3. 

Diagramme de sequence systeme enrichi 



Enrichissez le diagramme de sequence systeme precedent avec des activites 
internes interessantes et quelques reponses du Publiphone a l'appelant. 

En revanche, ne representez plus la conversation afin de vous concentrer sur 
les « operations systeme ». 



<>° n 

Nous avons ajoute au diagramme precedent les activites internes importantes du 
~0 Publiphone, telles que la verification des pieces et la gestion du solde de 
vT* l'appelant : 

• incrementation lors de 1' introduction de pieces ; 

• decrementation lors du debut de communication et a chaque UT. 



Figure 5-8. 

Diagramme de sequence systeme 
enrichi du scenario nominal 
de Telephoner 



: Appelant 



decrocherCombine 



introPiece(0,2 €) 



I incrementerCredit (0,2 €) 

1^ 



composerNumero (0562475200) 



acheminerNumero (0562475200) 



tonalite (libre) 



I 



tonalite(libre) 



jjaxer (0 ,2 €} 



introPiece (0,2 €) 



message envoys a soi 
meme symbol is ant un 
traitement interne 
important 



raccrocherCombine 
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Etape 3 - Representation du contexte dynamique 



Pour parfaire la preparation du diagramme d'etats, nous allons maintenant repertorier 
l'ensemble des messages qui sont emis et surtout ceux qui sont recus par le Publiphone. 
En effet, les messages recus vont devenir des evenements qui declenchent des transitions 
entre etats et les messages emis vont donner lieu a des actions sur les transitions. 

Le diagramme de sequence systeme realise a l'etape 2 liste un certain nombre de 
messages. Nous visons maintenant en la matiere a l'exhaustivite et a la 
« genericite ». Dans cette optique, nous preconisons de representer graphique- 
ment l'ensemble des messages echanges par le systeme avec ses acteurs sous la 
forme d'un diagramme de communication appele diagramme de contexte 
dynamique 4 . 



A retenir 


REPRESENTATION GRAPHIQUE DU CONTEXTE DYNAMIQUE 




Utilisez un diagramme de communication de la facon suivante : 




- le systeme etudie est represente par un objet 3 au centre du 




diagramme ; 




- cet objet central est entoure par une instance de chaque acteur ; 




- un lien relie le systeme a chacun des acteurs ; 




- sur chaque lien sont repertories tous les messages en entree et en 




sortie du systeme, sans numerotation. 



a. En realite, UML 2 parle egalement de ligne de vie pour les rectangles dans le diagramme de communication. . . 
Nous continuerons a utiliser le terme d'objet pour simplifier. 




EXERCICE 5-4. 

Diagramme de contexte dynamique 



Realisez le diagramme de contexte dynamique du Publiphone de la facon indi- 
quee precedemment. 



En partant des deux diagrammes de sequence systeme, nous avons repertorie 
O les messages echanges entre le systeme et ses acteurs. Puis nous les avons 
generalises en ajoutant des parametres quand c'etait necessaire : 



4. Comme pour le diagramme de contexte statique recommande au chapitre 1 , il ne s'agit pas d'un diagramme UML stan- 
dard. Cependant, notre experience pratique a montre qu'il etait tres utile sur les projets reels. 
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• introPiece(0,2 €) devient un message parametre : « introPiece(p) » ; 

• composerNumero(0562475200) devient « composerNumero(num) » ; 

• tonalite (libre) devient « tonalite(type) » pour prendre en compte 1' occupa- 
tion de la ligne, etc. 

Ce premier travail donne le schema preliminaire suivant : 



Figure 5-9. 

Version 

preliminaire du 
diagramme de 
contexte dynamique 



decrocherCombine 
introPiece(p) 
composerNumero(num) 

raccrocherCombine 
voixAppelant 

> 




messages 



: Appelant 



/ 1 tonalite(type) 
voixAppele 



« system » 
: Publiphone 



. systeme 



debuterComm 
UT 

tonalite(type) 
voixAppele 



acheminerNumero(num) 




finComm 




voixAppelant 




> 


: Standard 





Toutefois, prenons garde de ne pas oublier que nous sommes partis du dia- 
gramme de sequence systeme qui represente un scenario nominal du cas 
d'utilisation Telephoner. D'autres messages peuvent etre envisages entre le 
Publiphone et ses acteurs : 

• s'il reste des pieces inutilisees quand l'appelant raccroche, le Publiphone 
les lui rend ; 

• apres l'introduction de la somme minimale de 0,2 €, le Publiphone trans- 
met un message au standard pour le decompte du delai de 2 minutes ; 

• si le numero compose n'est pas valide, le standard le detecte ; 

• si l'appele raccroche le premier, la fin de communication est signalee par le 
standard ; 

• plus generalement, le standard transmet l'etat de la ligne au Publiphone 
(libre, occupee, en derangement, etc.), et pas seulement le type de tonalite. 

Le diagramme de contexte dynamique est done complete comme cela appa- 
rait sur la figure ci-apres. 
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: Appelant 



Figure 5-10. 

Version complete 
du diagramme de 
contexte dynamique 



decrocherCombine 
introPiece(p) 
composerNumero(num 
raccrocherCombine 
voixAppelant 

> 




tonalite(type) 
voixAppele 
rendrePieces 



« system » 
: Publiphone 



debuterComm 
UT 

tonalite(type) fa 
voixAppele 
etatLigne(etat) 
validiteNumero(v) 
finComm 
timeoutNumerotation 



messages 
parametres 



acheminerNumero(num) 
finComm 
voixAppelant 
timerNumerotation 

> 



: Standard 



Etape 4 - Description exhaustive par un diagramme d'etats 



Apres tout ce travail preliminaire, nous pouvons maintenant entreprendre une descrip- 
tion exhaustive de la dynamique du Publiphone. 

Le comportement du Publiphone n'est pas trivial, comme en temoigne par exemple le 
nombre eleve de messages identifies sur le diagramme de contexte dynamique. Nous 
preconisons dans ce cas une approche iterative et incrementale. C'est la demarche que 
nous allons mettre en ceuvre au travers des questions qui suivent. 



EXERCICE 5-5. 

Diagramme d'etats preliminaire 

Realisez un premier diagramme d'etats qui decrive le comportement nominal 
du Publiphone a pieces, d'apres le diagramme de sequence systeme. 

q Pour le cas d'utilisation Telephoner, l'etat initial nominal du Publiphone est a 
« raccroche en service ». Quand 1' appelant decroche le combine, il doit ensuite 
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introduire un minimum de 0,2 € pour pouvoir composer son numero. Une fois 
qu'un numero valide est compose, le Publiphone attend la reponse du standard, 
puis que l'appele decroche. La conversation est alors etablie jusqu'a ce que l'un 
des deux raccroche. Le Publiphone revient alors a son etat initial. 

Traduisons ce texte en un premier squelette de diagramme d'etats. 



Figure 5-11. 

Premiere version 
du diagramme 
d'etats 



when (credit >= 0,2€) 




reception de 
message 



A retenir EVE NE ME NT INTERNE : « WHEN » 

On notera que la plupart des evenements qui declenchent les transi- 
tions entre etats correspondent a la reception d'un message emis par un 
acteur. Nous avons d'ailleurs utilise les memes noms pour les evene- 
ments que pour les messages correspondants (sauf pour numeroValide 
qui est plus lisible que le rigoureux validiteNumero(vraij). 

Seul le passage de I'etat «Attente pieces » a I'etat «Attente numero » 
est provoque par un evenement interne au Publiphone : la detection du 
depassement du seuil des 0,2 €. UML propose un mot-cle pour distin- 
guer ces changements d'etats internes : « when», suivi d'une expres- 
sion booleenne dont le passage de faux a vrai declenche la transition. 
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EXERCICE 5-6. 

Diagramme d'etats (suite) 



Comment representer le fait que I'appelant peut raccrocher a tout moment et 
pas seulement dans I'etat conversation ? 

O II y a (comme souvent) deux f aeons de proceder : la triviale et 1' elegante ! La 
"o solution triviale consiste a ajouter des transitions declenchees par l'evene- 
vf* ment raccrocherCombine et sortant de tous les etats pour amener vers I'etat 
« Raccroche ». Mais le diagramme parait soudain bien charge. . . 



Figure 5-12. 

Solution triviale 




decrocherCombine 



Attente 
pieces 



when (credit >= 0,2€) 



raccrocherCombine 



raccrocherCombine 



Attente 
numero 



raccrocherCombine 



Communication 




composed 



raccrocherCombine 



debuterComm 



raccrocherCombine 



Attente 
validite 



Attente 
decrochage 



numeroValide 



La solution elegante consiste a introduire un super-etat 5 , « Decroche », ce qui 
permet de factoriser la transition de sortie vers I'etat « Raccroche ». 



5. On parte egalement d'etat « composite ». 
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Figure 5-13. 

Solution 
elegante 



super-e 



tat 



Raccroche 



decrocherCom 



raccrocherCombine 



transition 
f actori see 



► Decroche 

when (credit >= 0,2€) 



Attente 
pieces 



Attente 
numero 



Communication 



composed 



debuterComm 



Attente 
validite 



Attente 
decrochage 



numeroValide 



On notera egalement que nous aurions pu utiliser une notation un peu plus 
sophistiquee pour la transition de « Raccroche » vers « Attente pieces », 
comme cela est illustre sur le schema suivant. 



decrocherCombine 



Raccroche 



Figure 5-14. 

Solution elegante 
avec sous-etat 
initial 



sous-etat 
initial 



raccrocherCombine 




Decroche 

when (credit >= 0,2€) 



Communication 



debuterComm 



Attente 
numero 



composerN umero 



Attente 
validite 



Attente 
decrochage 



numeroValide 
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Au lieu d' avoir directement une transition entre « Raccroche » et « Attente 
pieces » , nous obtenons une premiere transition entre « Raccroche » et 
« Decroche », puis le symbole graphique de l'etat initial a l'interieur de 
« Decroche », afin d'indiquer explicitement le sous-etat initial. Cette maniere 
de proceder permet de decouper le diagramme d'etats en deux niveaux : 

• un premier niveau ne faisant apparaitre que les etats « Raccroche » et 
« Decroche » ; 

• un second niveau correspondant a la decomposition de « Decroche » . 

Cette possibilite de representation sur plusieurs niveaux est illustree sur la 
figure suivante, qui fait apparaitre le symbole de l'etat composite a l'interieur 
de « Decroche ». 

Figure 5-15. 

Representation 
des deux etats de 
plus haut niveau 6 



Nous conserverons dans la suite de l'etude de cas la transition directe par 
souci de simplicite. 



sm Publiphone 



decrocherCombine 



raccrocherCombine 




EXERCICE 5-7. 

Diagramme d'etats (suite bis) 



Comment le credit de I'appelant peut-il atteindre 0,2 € ? 
Considerez plusieurs solutions. 



Pour le moment, le credit de I'appelant n'intervient que dans l'expression 
"o booleenne associee a l'evenement interne « when ». Cependant, pour que le 
vT* credit atteigne 0,2 €, il faut que I'appelant introduise une ou plusieurs pieces. 

Nous pouvons done placer une transition propre (qui ramene vers l'etat de 
depart) sur l'etat « Attente pieces ». Des que le credit depasse 0,2 €, le Publi- 
phone doit passer dans l'etat « Attente numero ». 

Si nous ne souhaitons utiliser que des evenements de reception de messages, 
probablement introduirons-nous des conditions sur les transitions comme 
cela est illustre sur la figure 5-16. 

6. Le symbole « sm » en haut a gauche du diagramme signifie « State Machine », soit machine a etats en francais. 
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Figure 5-16. 



introPiece( p )[ p < 0,2€ ] 




conditions 



Premiere solution incorrecte 




introPiece( p )[ p >= 0,2€ ] 



Transition 



Attente 
numero 



propre 



Cette solution, qui parait evidente, est cependant erronee puisqu'elle interdit 
de composer un numero apres avoir introduit deux pieces de 10 cents... II 
faut done que le Publiphone memorise un attribut credit qui est incremente a 
chaque introduction de piece. 

II est tentant de transformer notre schema en ajoutant des actions et en modi- 
fiant les conditions. 



Helas, cette solution est egalement fausse, mais d'une maniere plus subtile ! 
En effet, la semantique d'une transition en UML est la suivante : lorsque 
l'evenement declencheur se produit, la condition est testee. Si (et seulement 
si) la condition est evaluee a vrai, la transition est declenchee et l'effet associe 
est alors realise. 

Voyons comment cela se passe concretement sur notre exemple, en partant de 
« Attente pieces » avec un credit initial de 0 € : 

• L' appelant introduit une piece de 10 cents. Le credit est inferieur a 0,2 € (il vaut 
0 €) : la transition propre est declenchee et le credit vaut maintenant 10 cents. 

• L' appelant introduit une piece de 10 cents. Le credit est inferieur a 02 € (il vaut 
10 cents) : la transition propre est declenchee et le credit vaut maintenant 0,2 €. 

Le resultat est surprenant : l'appelant a paye 0,2 € et ne peut toujours pas 
composer son numero... La moralite de ce constat est la suivante : n'essayez 
pas de tester une donnee dans une condition avant de l'avoir modifiee par une 
action ou activite, ce qui est le cas lorsqu'on veut tout faire tenir dans une 
seule transition. 



Figure 5-17. 



introPiece( p )[ credit < 0,2€ ] 
/ incremente rCredit(p) 



Seconde solution incorrecte 
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On en deduit aisement la solution correcte. 



Solution correcte 



Figure 5-18. 



introPiece( p ) 



f 



Attente 



/ incrementerCredit(p) 




Action, 
puis test 



piece 

i 



r 



Attente 



numero 



Cette facon de modeliser doit bien etre no tee, car elle peut etre reutilisee dans 
nombre de contextes. 



Completez la gestion du credit de I'appelant. 

N'omettez pas la derniere phrase : on peut ajouter des pieces a tout moment... 



Reprenons les choses par le debut. Admettons que le fait de decrocher le com- 
O bine fasse tomber les eventuelles pieces qui auraient ete introduites aupara- 
vant. Le credit doit done etre initialise a « 0 » sur cette transition. 

Ensuite, pour que le credit atteigne 0,2 €, il faut que I'appelant introduise une 
ou plusieurs pieces. Nous avons done place une transition propre sur l'etat 
« Attente pieces ». Des que le credit depasse 0,2 €, la transition de change - 
ment « when » amene le Publiphone en l'etat « Attente numero ». 

Le credit n'evolue plus jusqu'a ce que l'appele decroche, ce qui est traduit par 
le message debuterComm emis par le standard. En effet, a partir de ce 
moment la, le credit est decremente regulierement comme l'indique la phrase 5 
(« Le Publiphone consomme de l'argent des que l'appele decroche et a cha- 
que unite de temps [UT] generee par le standard »). L' action taxer represente 
la chute d'une piece a chaque impulsion. 

Enfin, il ne faut pas oublier de rendre les pieces non utilisees quand I'appelant 
raccroche. 




EXERCICE 5-8. 

Diagramme d'etats (suite ter) 
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La prise en compte de tous ces elements donne le schema presente ci-apres. 



Figure 5-19. 

Prise en compte de la gestion 
du credit 



1 



Raccroche 



raccrocherCombine / 
rendrePieces 



Decroche 
introPiece( p )/ incrementerCredit(p) 



decrocherCombine / 
credit = 0 



Attente 
piece 



when( credit >= 0,2€ ) 



Fin 

communication 



Attente 
numero 



UT[ credit suffisant ] / taxer 



Communication 



compos erNumero 



UT[ crepit insuffisant ] / 
taxer 



Attente 
validite 



debuterComm 
/ taxer 



Attente 
decrochage 



numero Valide 



On notera 1' introduction du nouvel etat « Fin communication » pour parer au 
cas ou la communication est interrompue par le Publiphone faute de credit 
suffisant. 

II nous reste encore a modeliser la derniere phrase : on peut ajouter des pieces 
a tout moment. La encore, plusieurs solutions sont possibles, mais une seule 
va s'averer tout a la fois correcte et elegante. 

La premiere idee consiste a introduire une transition propre identique a celle 
de « Attente piece » sur chaque sous-etat de « Decroche » . Cette facon de 
proceder est correcte, mais le dispositif est tres lourd, et nous allons plutot 
chercher a factoriser au moyen du super-etat. N'est-il pas possible de transfe- 
rer la transition propre au niveau meme de « Decroche », comme cela est 
illustre sur le schema ci-apres ? 
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factorisation de la 
transition propre 



introPiece( p ) / incrementerCredit(p) 



1 



Raccroche 



raccroche rCombine / 
rendrePieces 



Figure 5-20. 

Solution incorrecte 




Decroche 



decrocherCombine / 
credit = 0 



Attente 
piece 



when( credit >= 0,2€ ) 



UT[ credit suffisant ] / taxer 



Fin 

communication 

— 



UT[ crec it insuffisant ] / 
taxer 



Commu nication 



debuterComm 
/ taxer 



Attente 
decrochage 



Attente 
numero 



composerNumero 



Attente 
validite 



numeroValide 



Helas, cette solution n'est pas satisfaisante, comme nous allons le voir. 



A retenir TRANSITION PROPRE OU TRANSITION INTERNE ? 

Dans le cas d'une transition propre, I'objet quitte son etat de depart 
pour le retrouver. Cela peut avoir des effets secondaires non negligeables 
comme I'interruption puis le redemarrage d'une activite durable, la 
realisation d'effets en entree (« entry))) ou en sortie (« exit ») de 
I'etat, etc. De plus, quand un etat est decompose en sous-etats, une 
transition propre ramene forcement I'objet dans le sous-etat initial. 
Ici, chaque introduction de piece ramenerait le Publiphone dans 
I'etat «Attente piece », qui est implicitement sous-etat initial de 
« Decroche » ! 

Pour resoudre ce probleme courant, il existe en UML la notion de transi- 
tion interne ; elle represente un couple (evenement/effet) qui n'a 
aucune influence sur I'etat courant. La transition interne est ainsi notee 
a I'interieur du symbole de I'etat. 
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C'est l'approche que nous allons utiliser pour notre etude de cas. 



transition interne 
factorisee 



1 



Raccroche 



raccrocherCombine / 
rendrePieces 



transition 
propre m 

Figure 5-21. 

Solution correcte avec 
transition interne 
factorisee 



Decroche 



► intra Piece(p) / incrementerCredit(p) 



decrocherCombine / 
credit = 0 





Attente 




-_ 


piece 





when(credit > = 0, 2 €) 



Fin 

communication 



UT[ credit suffisant ] / taxer 




UT[ cred 



Communication 



insuffisant ] / 
taxer 



debuterComm 
/ taxer 



Attente 
decrochage 



Attente 
numero 



composerNumero 



Attente 
validite 



numeroValide 



On voudra bien noter aussi qu'en toute rigueur, la transition propre sur l'etat 
« Communication » devrait egalement etre une transition interne. En fait, 
lorsqu'il n'y a pas d'effet secondaire, on prefere utiliser la transition propre 
qui est plus visuelle. II faudra cependant etre vigilant si nous devons un jour 
decomposer « Communication » en sous-etats. . . 

Une deuxieme solution correcte, mais plus complexe, consiste a utiliser le 
pseudo-etat « History ». 



A retenir PSEUDO-ETAT « HISTORY » 

L'activation du pseudo-etat « History)) permet a un super-etat de se 
souvenir du dernier sous-etat sequentiel qui etait actif avant une tran- 
sition sortante. Une transition vers I'etat « History)) rend a nouveau 
actif le dernier sous-etat actif, au lieu de ramener vers le sous-etat 
initial. 
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Le diagramme 5-20 peut done etre corrige ainsi. 

introPiece( p ) / incrementerCredit(p) 



1 



Raccroche 



raccrocherCombine / 
rendrePieces 



Figure 5-22. 

Solution correcte alternative 
avec pseudo-etat 
« History » 



Decroche 



decrocherCombine / 
credit = 0 





Attente 


— " 




piece 






pseudo-etat 
"History" 



H 



when( credit >= 0, 2 €) 



Fin 

communication 

* — 



Attente 
numero 



UT[ credit suffisant ] / taxer 



UT[ cred 



Communication 



composerNumero 



t insuffisant ] / 
taxer 



Attente 
validite 



debuterComm 
/ taxer 



Attente 
decrochage 



numero Valide 



EXERCICE 5-9. 

Diagramme d'etats (fin) 



Completez le diagramme d'etats pour prendre en compte I'ensemble de I'enonce. 
Proposez des complements si vous le pensez necessaire. 



O Reprenons les phrases de I'enonce une a une. Nous avons traite en detail les 
"o phrases 1 , 5 et 6. En revanche, nous n'avons pris en compte que tres partielle- 
vJ^ ment les phrases 2, 3 et 4. 

Voyons tout d'abord la phrase 2 : 

2. Apres V introduction de la monnaie, Vutilisateur a 2 minutes pour com- 
poser son numero (ce delai est decompte par le standard). 
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Le delai etant decompte par le standard, nous avons introduit deux messages 
dans le diagramme de contexte (voir figure 5-10) : 

• timerNumerotation envoye par le Publiphone au standard ; 

• timeoutNumerotation envoye par le standard au Publiphone. 



A retenir ENVOI DE MESSAGE : « SEND » 

UML propose un mot-cle « send» pour representer Taction importante 
qui consiste a envoyer un message a un autre objet sur declenchement 
d'une transition. 

La syntaxe de cette action particuliere est la suivante : « / send 
cible.message » b . 



b. Attention, dans des versions anciennes d'UML, la notation etait plus sibylline : « A cible .message ». 



Dans le diagramme d'etats du Publiphone, nous aurons done une transition 
qui sera declenchee par la reception du message timeoutNumerotation, et 
l'envoi du message timerNumerotation a l'entree de l'etat « Attente 
numero » , comme cela est illustre sur le schema suivant. 




II faut noter que nous avons renomme l'etat « Fin communication », car cet 
« etat puits » (e'est-a-dire n'ayant aucune transition en sortie) nous servira 
egalement pour tous les cas d'erreur. 

Passons maintenant a la phrase 3 : la ligne peut etre libre ou occupee. 

Pour le moment, nous avons suppose que la ligne etait libre et que le corres- 
pondant decrochait. Nous allons introduire dans le modele la possibilite que 
le standard renvoie un etat ligne (occupee), mais egalement que l'appele ne 
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decroche pas (ce qui n'est pas prevu explicitement dans l'enonce). Pour ce 
dernier cas, nous supposons que le standard envoie un message timeoutAppel 
qui amene le Publiphone dans l'etat d'erreur. 

La phrase 4 ajoute simplement une transition entre les etats « Communication » 
et « Fin communication » : le correspondant peut raccrocher le premier. 

Le diagramme d'etats complete est represents ci-apres sur le schema suivant. 



Figure 5-24. 

Modelisation complete de toutes 
les phrases de I 'enonce 



^ Raccroche 



IV 



raccrocherCombine / 
rend rePieces 



Decroche 



introPiece(p) [p OK] / incrementerCredit(p) 



decrocherCombine / 
credit = 0 



condition sur la 
validite de la piece 



phrase 4 



3 



Attente 
piece 



^ when( credit >= 0,2€ ) 

/ send standard. timerNumerotation 



timeout Nume rotation 



raccrochage appele 



Fin commun ication 
ou erreur 



UT[ credit 
suffisant ] / taxer 



UT[ credit 
i isuffisant ] / 
taxer 



Commu nication 
do/ transmettreVoix - 



A 



debut erComm 
/ taxer 



etatl_igne( oc ;upee ) 



phrase 3 



1 




numerolnvalide 



timeoutA| pel 



ajoT ts et 
comp! ements 



Attente 
numero 




compose Numero 
/ send standarc .acheminerNumero 



Attente 
validite 



Attente 
decrochage 



nume roValide 
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EXERCICE 5-10. 

Diagramme de contexte statique etendu 



5> 



o 



En vous servant de toute cette etude dynamique, proposez une version eten- 
due du diagramme de contexte statique qui fasse apparaTtre les attributs et 
les operations de la classe Publiphone. 

on 

Nous allons appliquer quelques regies simples : 

• Les operations publiques correspondent aux noms des messages emis par 
les acteurs. 

• Les operations privees correspondent aux noms des messages envoyes a 
soi-meme. 

• Les attributs correspondent aux noms des donnees remanentes, manipulees 
dans les effets ou les conditions. 

Voyons tout d'abord les operations publiques. D'apres le diagramme de con- 
texte dynamique (voir figure 5-10), nous pouvons identifier : 

• decrocherCombine 

• introPiece(p) 

• composerNumero(num) 

• raccrocherCombine 

• debuterComm 

• UT 

• etatLigne(etat) 

• validiteNumero(v) 

• finComm 

• timeoutNumerotation 

Le diagramme d'etats (voir figure 5-24) nous amene a ajouter l'operation 
suivante : 

• timeoutAppel 

Passons maintenant en revue les operations privees. Le diagramme de 
sequence systeme enrichi (voir figure 5-8) montrait les messages suivants : 

• verifierPiece 

• incrementerCredit 

• taxer 



Sur le diagramme d'etats, nous avons introduit l'activite durable « dol 
transmettreVoix » , qui peut etre ajoutee a la liste des operations privees 
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(puisqu'elle est declenchee indirectement par l'arrivee dans l'etat 
« Communication »). On notera que l'operation verifierPiece s'est traduite 
par une condition « [p OK] » sur la transition interne factorisee. 

Enfin, quels sont les attributs interessants ? II est clair qu'une donnee impor- 
tante est celle qui est geree d'une fa9on permanente par le Publiphone : le 
credit de 1' appelant. Du coup, nous pouvons eliminer les operations implicites 
de lecture/ ecriture de cet attribut (incrementer -Credit, taxer). 

Nous en savons assez pour dessiner le diagramme de contexte statique 
etendu. 



A retenir DIAGRAMME DE CONTEXTE STATIQUE ETENDU 

Nous appelons « diagramme de contexte statique etendu » un 
diagramme de contexte statique dans lequel nous ajoutons des attri- 
buts et des operations de niveau systeme a la classe qui represents le 
systeme (apprehende comme une boTte noire), ainsi qu'aux acteurs non- 
humains. 



Figure 5-25. 

Diagramme de contexte 
etendu 




0..1 



Appelant 



«actor» 
Standard 



■ acheminerNumero(num) 

■ finCommO 

■ timerNumerotationO 



0..1 

r 



operations 
publiques 



< 



0..1 



operations 
privees 



■C 



«system» 
Publiphone 
credit = 0 



h decrocherCombine() 

i- introPiece(p) 

i- composerNumero(num) 

i- timeoutNumerotationO 

h validiteNumero() 

i- etatLigne(etat) 

i- timeoutAppelQ 

h debuterCommQ 

i-UT() 

i- finComm() 

i- raccrocherCombine() 

verifierPiece(p) 

transmettreVoix() 



On notera que nous avons fait figurer les operations publiques sur l'acteur 
non-humain Standard, mais pas sur l'acteur Appelant. Le concept d'operation 
n'a pas de sens sur un acteur humain : on ne cherche generalement pas a le 
modeliser d'une facon deterministe. Sur un acteur non-humain, en revanche, 
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la liste des operations represente son interface (au sens d'une API, par exem- 
ple) telle qu'elle est utilisee par le systeme etudie. C'est particulierement utile 
pour verifier l'interoperabilite des deux systemes et s' assurer que ces opera- 
tions sont deja disponibles, ou prevues dans les specifications. 

Au point de vue notation UML, rappelons que : 

• « - » signifie prive ; 

• « + » signifie public ; 

• « = » permet de specifier la valeur initiale d'un attribut. 
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■ Activite continue/finie ■ Transition automatique 

■ Evenements « after » et « when » ■ Regions 
concurrentes n Effets d'entree (entry) ou de sortie 
(exit) ■ Action - flot ■ Decision ■ Embranchement 
- jonction. 



Ce chapitre va nous permettre de completer, au moyen de 
plusieurs petits exercices, le passage en revue des principales 
difficultes que pose la construction des diagrammes d'etats 
UML, a savoir : 

• activite continue ou finie, transition automatique ; 

• pseudo-evenements after et when ; 

• regions concurrentes ; 

• effets d'entree [entry) et de sortie [exit] ; 

• points d'entree et de sortie ; 

• heritage de transitions d'un super-etat. 

Nous reverrons egalement les bases du diagramme d'activite, 
ainsi que les nouveautes les plus interessantes introduites par 
UML 2. 
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Nous avons deja traite des diagrammes de sequence aux 
chapitres 1 et 2, mais nous les reverrons ici, ainsi que les 
diagrammes de communication dans la partie consacree a la 
conception. 



Concepts de base du diagramme d'etats 



J: 



Exercice 6-1. 

Diagramme d'etats d'une partie d'echecs 

Dessinez le diagramme d'etats correspondant au deroulement d'une partie 
d'echecs. 

O Commencons par representer le comportement sequentiel d'une partie, 
~0 sachant que les Blancs commencent. 

Figure 6-1. 

Debut du diagramme d'etats de la partie 




Representons ensuite par des etats finaux differents les trois issues possibles : 
gain blanc (1-0), gain noir (0-1) et partie nulle (1/2-1/2). Nous n'avons pas 
cherche l'exhaustivite, les regies des echecs de competition etant nettement 
plus complexes que ce qui est dessine sur le schema suivant. 



Figure 6-2. 

Diagramme d'etats 
de la partie 



En cours 
coup blanc 



/ ■> 

Trait aux 




Trait aux 


Blancs 
* . w a 


coup noir 


Noirs 




pat 



Nulle 



repetition de coups 



mat 



mat 



Gain noir 
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Si nous souhaitons ajouter la possibilite de commencer une partie a partir 
d'une position donnee a la place de la position initiale standard, nous sommes 
amenes a utiliser la nouvelle notation du point d'entree (« entry point »). Le 
cercle blanc nomme « Position » sur la figure 6-3 permet de demarrer directe- 
ment une partie dans l'etat « NoirsJouent » si on le desire, alors que le sous- 
etat initial par defaut est « B lanes Jouent », comme indique par la fleche posi- 
tionnee au-dessus de ce sous-etat. Les evenements « pat » et « repetition » 
sont factorises, alors que « abandon » et « mat » menent a des etats de sortie 
differents suivant l'etat source. La notation du point de sortie (« exit point ») 
consiste en une croix a l'interieur d'un cercle blanc. Elle est egalement nou- 
velle et propre a UML 2. 



Figure 6-3. 

Diagramme d 'etats 
complete de la partie 



ParteEncours 



[ t r "it VI. hi".,--.] 



Bljn.isjouent 



t«iui'Bl.inc 



eoupNotr 




(ir hi aux Nous] 



Position 



pat 



i"|irtitmn j 



Partiel Julie 



■iainBlanc 



^aintJnir 



EXERCICE 6-2. 

Diagramme d'etats simple 

Considerons un reveille-matin simplifie : 

• on peut mettre l'alarme « on » ou « off » ; 

• quand l'heure courante devient egale a l'heure d'alarme, le reveil sonne sans 
s'arreter ; 

• on peut inteiTompre la sonnerie. 

Dessinez le diagramme d'etats correspondant. 

Voyons tout d'abord la premiere phrase : 
v5^ 1- On peut mettre l'alarme « on » ou « off ». 
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Le reveil a clairement deux etats distincts : Desarme (alarme « off ») ou Arme 
(alarme « on »). Une action de l'utilisateur permet de passer d'un etat a 
1' autre. On suppose que le reveil est bien desarme au depart. Notez le parame- 
tre heureAlarme de 1' evenement armer. 



Figure 6-4. 

Diagramme d' etats de la phrase 1 



armer( heureAlarme ) 



V 



Desarme 



Arme 



desarmer 



Considerons maintenant les deux autres phrases : 

2. Quand Vheure courante devient egale a I'heure d' alarme, le reveil sonne 
sans s'arreter ; 

3. On peut interrompre la sonnerie. 

Le fait de sonner constitue un nouvel etat pour le reveil. II s'agit bien d'une 
periode de temps durant laquelle le reveil effectue une certaine activite (son- 
ner) qui dure jusqu'a ce qu'un evenement vienne l'interrompre. 



Figure 6-5. 

Diagramme 

d 'etats preliminaire 

du reveille-matin 



armer( heureAlarme ) 



Desarme 



when( heureCourante = heureAlarme ) 



Arme 



Sonnerie 



desarmer 



arretSonnerie 



Le passage de l'etat Arme a l'etat Sonnerie est declenche par une transition due a un 
changement interne, represente au moyen du mot-cle « when ». En revanche, d'apres 
l'enonce, le retour de l'etat Sonnerie a l'etat Arme ne s'effectue que sur un evenement 
utilisateur. 




EXERCICE 6-3. 

Activite finie et transition automatique 



Completez le diagramme d'etats precedent pour prendre en compte le fait que 
la sonnerie du reveil s'arrete d'elle-meme au bout d'un certain temps. 
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^ II y a done une deuxieme possibilite de sortie de I'etat Sonnerie : quand le 
q reveil s'arrete tout seul de sonner au bout d'un certain temps. 

A retenir ACTIVITE CONTINUE OU FINIE - TRANSITION AUTO M ATI QUE 

Une activite durable a I'interieur d'un etat peut etre soit : 

- « continue » : elle ne cesse que lorsque se produit un evenement qui 
fait sortir I'objet de I'etat ; 

- « finie » : elle peut egalement etre interrompue par un evenement, 
mais elle cesse de toute facon d'elle-meme au bout d'un certain 
temps, ou quand une certaine condition est remplie. 

La transition de completion d'une activite finie, aussi appelee transition 
automatique, est representee en UML sans nom d'evenement ni mot- 
cle. 



Dans notre exemple, il suffit done d'ajouter une activite durable sonner a 
I'etat Sonnerie et une transition automatique en sortie de cet etat. Le dia- 
gramme d'etats complete est represente sur le schema suivant. 



armer( heureAlarme ) 



when( heureCourante = heureAlarme ) 



Desarme 



Arme 



Figure 6-6. 

Diagramme d'etats 
complete du reveille-matin 



desarmer 



arretSonnerie 



transition b 
automatique 



Sonnerie 



do/ sonner 



activite 
durable 



II convient aussi de se demander si l'utilisateur a le droit de desarmer le reveil 
pendant qu'il sonne. Dans ce cas, il faudrait ajouter une transition declenchee 
par desarmer et allant directement de Sonnerie a Desarme. 
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EXERCICE 6-4. 

Diagramme de contexte statique 

Deduisez-en le diagramme de contexte statique etendu du reveil (voir 
exercice 5-10). 



O Si Ton applique de nouveau les regies enoncees lors de l'exercice 5-10, on 
"o obtient sans difficulte le diagramme ci-apres. 



Figure 6-7. 

Diagramme de contexte 
statique etendu 




0..* 



Utilisateur 



«system» 
Reveil 



heureCourante = 00.00 
heureAlarme = 00.00 



+ armer(heureAlarme) 
+ desarmer() 
+ arretSonnerie() 
- sonnerQ 



Exercice 6-5. 
Diagramme d'etats simple 

Considerons une montre a cadran numerique simplifiee : 



Figure 6-8. 

Montre a cadran numerique simplifiee 




Bouton mode 



Bouton avance 



1 . Le mode courant est le mode « Affichage ». 

2. Quand on appuie une fois sur le bouton mode, la montre passe en « modification 
heure ». Chaque pression sur le bouton avance incremente l'heure d'une unite. 

3. Quand on appuie une nouvelle fois sur le bouton mode, la montre passe en 
« modification minute ». Chaque pression sur le bouton avance incremente les 
minutes d'une unite. 

4. Quand on appuie une nouvelle fois sur le bouton mode, la montre repasse en mode 
« Affichage ». 
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J- 

O 



Dessinez le diagramme d'etats correspondant. 

on 

On obtient sans difficulte particuliere ce diagramme d'etats typique, qui est 
presente sur le schema suivant. 



1 



appui bouton avance / heure++ 



Affichage 



appui bouton mode 



Figure 6-9. 

Diagramme d'etats 
preliminaire de la 
montre a cadran 
numerique 



A 



appui bouton avance / minute ++ 



Modification 
heure 



appui bouton mode 



Modification 
minute 



appui bouton mode 



On remarquera les notations en style C++ ou Java pour les actions : 
« heure++ » et « minute++ ». UML n' impose pas de « langage d' action » 
nous pouvons done en exprimer le detail comme nous le souhaitons : texte 
libre, pseudo-code, etc. 

Nous obtenons des transitions propres sur les etats de modification et pas sur 
l'etat d'affichage. Cela veut-il dire que l'evenement « appui bouton avance » 
est impossible dans l'etat « Affichage » ? Non, bien sur. Cela signifie plutot 
que, comme cet evenement n'a aucun effet dans cet etat, il ne declenche 
aucune transition. L'evenement est purement et simplement perdu. 



Concepts avances du diagramme d'etats 




EXERCICE 6-6. 

Evenement temporel 



Ajoutez le comportement suivant : quand on appuie sur le bouton avance plus 
de deux secondes, les heures (ou les minutes) s'incrementent rapidement 
jusqu'a ce qu'il se produise un relachement dans la pression du bouton. 

Envisagez plusieurs solutions possibles. 



Dans l'exemple precedent, les evenements d'appui sur les boutons correspon- 
O daient en fait au couple indivisible « pression » et « relachement » . Nous 
avions considere que la duree de pression sur chaque bouton etait negligeable 
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par rapport aux durees des etats ou, en tout cas, non significative. Avec le 
nouvel enonce, ce n'est plus le cas, puisque la duree de pression sur le bouton 
avance influe sur le comportement de la montre. La bonne approche consiste 
a introduire un nouvel evenement : « relachement bouton avance », afin de 
pouvoir gerer le temps de pression. 

Le diagramme suivant montre 1' utilisation du nouveau timing diagram 
d'UML2. 



Figure 6-10. 

Timing diagram : 
transformation 
d'un evenement 
en deux 



Appui /relachement 
bouton avance 



Bouton 
appuye 



Bouton 
relache 



Relachement 
bouton avance 




Temps 



Une premiere solution, tentante, consiste a introduire une condition sur la 
duree de pression, ainsi qu'un nouvel etat « Incrementation rapide », comme 
cela est illustre sur la figure suivante : 



Affichage 



Figure 6-11. 

Modification erronee 
du diagramme d' etats de 
la montre a cadran 
numerique 



appui bouton mode 



Sppui bouton avance[ 
appui < 2 s ] j heure++ 



appui bouton mode 





appui bouton mode 



Modification 
minute 



relachement 
bouton avance 




relachement 
bouton avance 



^uton ava!sce[ 
slppui >= 2 s) 



Increment 
rapide heure 



Increment 
rapide minute 



Pourtant, cette solution qui semble evidente n'est pas acceptable en UML. 

En effet, un evenement (comme une transition) est par convention instantane, 
ou en tout cas insecable (atomique). II est done tout a fait inapproprie de tester 
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sa duree ! Les seuls concepts dynamiques en UML pour lesquels la notion de 
duree est significative sont l'etat et l'activite durable. II faut done s'en servir 
pour resoudre cet exercice. Deux solutions sont possibles : toutes les deux 
necessitent que Ton ajoute un etat intermediaire pour que Ton puisse tester la 
duree de pression sur le bouton avance, mais elles different quant a la facon de 
realiser ce test : 

• La premiere approche consiste a introduire une activite finie « attendre 2 s » 
dans l'etat intermediaire et une transition automatique qui represente le fait 
que le bouton est appuye plus de deux secondes. 

• La seconde approche consiste a utiliser un autre mot-cle propose par UML : 
le pseudo-evenement « after », suivi d'une duree en argument represen- 
tant l'echeance d'un timer. 

Pour illustrer les deux solutions, nous les avons representees ensemble sur le 
diagramme suivant mais, dans la realite, il faudrait bien sur en choisir une 
seule et l'appliquer aux deux etats de modification. Pour notre part, nous 
recommandons la seconde solution qui nous semble plus simple et plus facile 
a lire. 



Figure 6-12. 

Les deux possibilites 
pour proceder d une 
modification correcte 
du diagramme d' etats 
de la montre a cadran 
numerique 



Affichage 



appui bouton mode 



aDDui bouton mode 



appui bouton mode 



Modification 
heure 



relachem 
bouton avance 



appui bouton 
avance / 
heure++ 



Gestion bouton 
avance 



relachemenf 
bouton avano 




relacherr ent 
bouton av 



Increment 
rapide heure 



Modification 
minute 



bouton 



A 



relachsment 



appui bouton 
avance / 
minute ++ 



Bouton 
appuye 



Increment 
rapide minute 



l re approche : activite 
finie et transition 
automatique 




2 approche : 
evenement temporel 



On notera que le comportement initial est conserve : si le bouton avance est relache en morns 
de deux secondes, les heures (ou les minutes) sont bien incrementees d'une unite. En fait, la 
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transition propre qui existait sur chaque etat de modification a pu etre coupee en deux suite a 
la separation des deux evenements « appui » et « relache », et a l'ajout de l'etat intermediaire. 




EXERCICE 6-7. 

Recapitulatif 



Modelisez le comportement du videoprojecteur lors d'une session de formation. 

Commencez par identifier les etats et transitions « nominaux ». Ajoutez les 
periodes de prechauffage et de refroidissement de la lampe. Representez 
ensuite le fait qu'il faut appuyer successivement deux fois en moins de 5 s sur 
le bouton power pour interrompre la videoprojection. Envisagez enfin la 
panne de la lampe... 



O Commencons par identifier le scenario nominal d'utilisation du videoprojec- 
~0 teur : le brancher, puis l'allumer (bouton power), puis connecter l'ordinateur. 
vT* Ensuite, l'eteindre, puis le debrancher. 

Si nous ajoutons la possibility de l'eteindre alors qu'il est allume ou connecte, 
puis celle de le debrancher intempestivement, nous arrivons au diagramme de 
la figure 6-13. 



Figure 6-13. 

Premiere 
version du 
diagramme 
d' etats du 
videoprojecteur 



sm Videoprojecteur (simple) 



V 



A 




nnecter source 



Ajoutons le comportement suivant : si Ton eteint le videoprojecteur sans le 
deconnecter de sa source, il repassera directement dans l'etat Connecte quand 
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on le rallumera. Les deux etats Allume et Connecte integrent chacun une acti- 
vite durable : respectivement la projection d'un ecran bleu ou de la source 
d'entree. Le diagramme devient alors comme indique sur la figure 6-14. 



Figure 6-14. 

Deuxieme 
version du 
diagramme 
d 'etats du 
videoprojecteur 




Ajoutons maintenant les activites continues de prechauffage et de refroidisse- 
ment de la lampe. II est done necessaire d'introduire deux etats supplementai- 
res autour de l'etat Eteint. 

Comment sortir de ces etats supplementaires : soit en utilisant un evenement 
de changement (when) testant la temperature de la lampe, soit plus simple- 
ment une transition automatique. Nous utiliserons cette derniere solution, 
plus simple et n'obligeant pas a specifier les temperatures visees. 

Verifions que nous avons pris en compte tous les scenarios : d'abord le com- 
portement nominal en debut de session de formation : Debranche - brancher 
- Eteint - power - Prechauffage - [source absente] - Allume - connecter 
source - Connecte. Puis, a la pause, le formateur eteint le projecteur : 
Connecte - power - Refroidissement - Eteint. Ensuite, de retour dans la salle, 
il rallume le projecteur et n'a pas besoin de reconnecter la source : Eteint - 
power - Prechauffage - [source presente] - Connecte. 
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sm VideoProjecteur (3e) 



Debranche \_ 



> 



Prechauffage 



io I prechauffer lampe 



7F 



[source ab;ente] 



[source prest nte] 



Refroidissement 



do / refroidir lampe 



< 



IT 



do / projeter ecran bleu 

IK 

deconnect?r source 

connecte 

W 



do / projeter source 



< 



Figure 6-15. 

Troisieme version du diagramme 
d'etats du videoprojecteur 



Pour eviter de perdre trop de temps lors d'un appui intempestif sur power 
dans l'etat Connecte, les videoprojecteurs modernes demandent une confir- 
mation sous la forme d'un deuxieme appui sur power en moins de 5 s. 

Nous avons vu lors de l'exercice precedent l'evenement temporel after 
(delai ) qui va nous servir ici, associe a un nouvel etat transitoire d'attente 
de confirmation. 
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sm VideoProjecteur (4e) 



V 



f Eteint N 



> 



Prechauffage 



do / prechauffer lampe 



[source ab ente] 



V 



[source press nte] 



Refroidissement 



do / refroidir lampe 



< 



do / projeter ecran bleu 

7K 

deconnect^r source 

connecte 



/Attente confirmatio 



after [5s] 



> 



< 



do / projeter source 



< 



Figure 6-16. 

Quatrieme version du diagramme 
d'etats du videoprojecteur 



Ajoutons enfin l'evenement redoute : la lampe peut griller des lors que le pro- 
jecteur n'est pas eteint. Le plus simple consiste a introduire un nouvel etat 
composite a l'interieur de Branche mais excluant Eteint. II suffit alors d'intro- 
duire une transition factorisee declenchee par l'evenement interne de change- 
ment when (etat lampe = grillee), qui amene vers un etat de panne. 
Le diagramme complet est represente sur la figure 6-17. 
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sm VideoProjecteur (complet) 



V 



> 



Debranche 



deb ran cher 



A 



debrancher 



Refroidissement 




do / refroidir lampe 

s A~~ 

power 



Prechauffage 



do / prechauffer lampe 



/^Attente confirmatiorT\ 



[source presente] 





[sourc e absente] 



jL 



Pret 



after (5s) 



Connecte 




dec^rhnecter 
Durce 



connecter source 



Debranche en 
panne 



when (etat la npe = grillee) 

V 



debrancher 



< 



Figure 6-17. 

Version finale du diagramme d'etats 
du videoprojecteur 
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EXERCICE 6-8. 

Regions concurrentes 



Bouton eclairage 



Bouton alarme 



Bouton mode 



Bouton avance 



Reprenons notre exemple de montre a 
cadran numerique tel qu'il etait 
presente au debut de l'exercice, et ajou- 
tons maintenant a cette derniere deux 
autres boutons : 

• un bouton eclairage ; en le pressant, 
on eclaire le cadran de la montre, 
jusqu'a ce qu'on le relache ; 

• un bouton alarme, qui ajoute a la montre digitale une fonctionnalite classique d' alarme, 
comme cela a ete decrit lors du premier exercice de ce chapitre (reveille-matin). 




Figure 6-18. 

Montre a cadran numerique completee 



Dessinez le diagramme d'etats complet incluant tous les comportements de la 
montre. 



Nous sommes clairement en presence de trois comportements concurrents : 
O • la gestion de l'afflchage ; 

• la gestion de 1' alarme ; 

• la gestion de l'eclairage. 

Commencons par le plus simple d'entre eux, qui concerne la gestion de 
l'eclairage. Cette derniere peut se modeliser tres simplement par un automate 
a deux etats, comme nous l'illustrons sur le schema suivant. 



Figure 6-19. 

Diagramme d'etats 

de la gestion de I 'eclairage 



Eteinte 



appuiEclairage 



relacheEclairage 



Eclairee 



do/ eclairerCadran 



Si la gestion de l'eclairage peut tout a fait se modeliser a part, il n'en est pas 
de meme pour l'affichage et 1' alarme. En effet, il faut maintenant pouvoir 
aussi modifier l'heure d'alarme et la minute d'alarme, ce qui ajoute deux nou- 
veaux etats au diagramme de la figure 6-9, comme cela est indique ci-apres. 
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Figure 6-20. 

Diagramme d'etats de la gestion 
de Vaffichage 



Affichage 



appuiMode 



appuiAvance / heureCourante++ 



appuiAvance / minuteCourante++ 



appuiMode f Modification 
^ heure 



appuiAvance / minuteAlarme++ 



Modification 
minute alarme 



appuiMode ( Modification 

^ minutp 



appuiAvance / heureAlarme++ 



appuiMode 



Modification 
heure alarme 



appuiMode 



Nouveaux etats 



II reste maintenant a modeliser la gestion de 1' alarme. Nous pouvons nous 
inspirer du diagramme d'etats du re veil (voir figure 6-6) pour obtenir le 
schema suivant. On y notera la dependance avec la gestion de 1' affichage via 
le test effectue par la gestion de 1' alarme sur les attributs (« when »...). 



Figure 6-21. 

Diagramme d'etats de 
la gestion de V alarme 



appuiAlarme 



Desarmee 



appuiAlarme 



A 



when( heureCourante=heureAlarme AND 
minuteCourante=minuteAlarme ) 



Armee 



Sonnerie 



do/ sonner 



appuiAlarme 



Nous avons done obtenu trois diagrammes d'etats. Comment faire en sorte 
que ces trois diagrammes separes decrivent le comportement de la montre a 
cadran numerique ? 

La encore, deux solutions sont possibles : 

• Considerer que toute instance de Montre contient en fait trois instances et 
que chacune gere un des trois comportements decrits precedemment. Toute 
montre delegue ainsi une partie de sa dynamique a une instance d'afficheur, 
d' eclair age ou d' alarme, suivant le cas. On peut representer cela au moyen 
d'une relation de composition dans un diagramme de classes. Toutefois, 
UML 2 permet une meilleure solution : utiliser le concept de classe struc- 
turee (revoir l'exercice 4-5), ou meme de composant. Nous en profitons 
pour illustrer le connecteur de delegation (« delegate »). Celui-ci relie le 
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contrat externe du composant (ses interfaces) a la realisation de ce compor- 
tement par ses parties. 



Figure 6-22. 

Diagramme 
de structure 
composite 
qui montre 
la relation 
de delegation 



l_Eclairage 



Montre 



heureCourante: Horodatage 
heureAlarme: Horodatage 



alarme [1] 



«interface» 
l_Eclairage 



appuiEclairageQ : void 



- interface" 
l_Alarme 



appuiAlarmeQ : void 



■■interface" 
^Afficheur 



appuiModeQ : void 
appuiAvanceQ : void 



• Decrire des « regions concurrentes » au sein du diagramme d'etats de la 
classe Montre. L'etat courant de la montre devient alors un vecteur a trois 
lignes : etat de l'afnchage, etat de l'alarme, etat de l'eclairage. Une montre 
peut simultanement etre en affichage de modification minute, etre en train 
de sonner et etre eclairee. 

Le diagramme d'etats de la montre avec trois regions concurrentes apparait 
sur le schema ci-apres. 
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Figure 6-23. 

Diagramme d' Stats de la montre avec 
regions concurrentes 



appuiAvance / heureCourante++ 



appuiAvance / 
minuteCqtfrctote++ 



appuiMode f Modification 
^1 minute 




appuiMode 



appuiMode 



Liens entre 
regions via 

ommunej 



Jl " — ~ donnees c omnium 

Regions when ^ heureCourante=heureAlarme AND 
concurrentes 

/ V 



appuiAlarme 



when( Y 

minuteCourante=minuteAlarme ) 



Desarmee 


appuiAlarme 


r Armee 


<S 






«£ 






i 


\ 




appuiAlarme 





appuiEclairage 



relacheEclairage 



do/ eclairerCadran 



On notera que chaque « region » doit etre initialisee puisque, si les etats sont bien exclusifs a 
Tinterieur d'une region concurrente, ils existent simultanement dans les trois regions. 
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EXERCICE 6-9. 

Diagramme d'etats hierarchique 



Considerons le fragment de diagramme d'etats suivant, qui contient de nombreux effets. 



Figure 6-24. 

Exemple de diagramme 
d'etats complexe 



El/xl 




E3/x3 



Super-EtatA 



entry / A_In 
E4 /AJnterne 
exit /A Out 



I 

> 


i 
> 


E5 
► 




[ Etat B 


f Etat C 1 


entry / B in 
exit / B_Out 

t J 




entry / C_In 

exit/C Out 
v. ) 





A retenir EFFETS D'ENTREE (OU DE SORTIE) - ENTRY (EXIT) 

Un effet d'entree (introduit par le mot-cle « entry)) a I'interieur du 
symbole d'un etat) represents une action ou une activite qui est 
execut.ee chaque fois que Ton entre dans cet etat. Cela permet de 
factoriser un meme effet qui sera declenche par toutes les transitions 
qui entrent dans I'etat. 

L'effet de sortie (introduit par le mot-cle « exit ») est I'effet syme- 
trique en sortie de I'etat. 



Le diagramme de l'enonce comprend done : 

• une transition propre sur le super-etat (E3/x3) ; 

• une transition interne dans le super-etat (E4/A_Interne) ; 

• des transitions d'entree et de sortie dans le super-etat et chacun des sous-etats. 

Nous allons etudier l'ordre temporel d'execution des effets en completant le tableau 
suivant. Nous partirons de I'etat a gauche du diagramme symbolise par «... », et nous 
prendrons comme nouvel etat de depart I'etat d'arrivee de la ligne precedente. 
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Etat de depart 


Evenement 


Effets 


Etat d'arrivee 




El 


7 


7 


? 


E5 


7 


? 


7 


E4 


? 


7 


? 


E6 


7 


? 


7 


E3 


7 


7 


? 


E5 


7 


? 


7 


E3 


7 


7 


7 


E2 


7 


7 



Completez le tableau precedent. 



Dans l'etat de depart, symbolise par « . . . » a gauche du diagramme, l'evene- 
O ment El declenche l'effet xl, puis conduit au super-etat A. Cette entree dans le 
vT 1 super-etat A declenche l'effet d'entree A_In, puis l'entree dans le sous-etat B (a 

cause du symbole du sous-etat initial), et done l'effet d'entree B_In. 



Etat de depart 


Evenement 


Effets 


Etat d'arrivee 




El 


xl , A_In, B_In 


B (dans A) 



Dans l'etat B, l'evenement E5 fait sortir de l'etat et declenche done l'effet 
B_Out, puis conduit a l'etat C et declenche en consequence C_In. 



Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


B 


E5 


B_Out, C_In 


C (dans A) 



Dans l'etat C, l'evenement E4 est-il possible ? Oui, car les transitions inter- 
nes sont heritees du super-etat. L'evenement E4 fait done rester dans l'etat C 
et declenche simplement l'effet A_Interne. 



Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


C 


E4 


A_Interne 


C (dans A) 
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Dans l'etat C, l'evenement E6 fait sortir de l'etat et declenche done C_Out, 
puis conduit a l'etat B et declenche en consequence B_In. 



Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


C 


E6 


C_Out, B_In 


B (dans A) 



Dans l'etat B, l'evenement E3 est-il possible ? Oui, car les transitions propres 
sont heritees du super-etat. L'evenement E3 fait d'abord sortir de l'etat B et 
declenche l'effet B_Out, puis fait sortir du super-etat A et declenche A_Out, 
declenche ensuite x3, puis fait entrer dans le super-etat A et declenche A_In, 
enfm fait rentrer dans l'etat B et declenche B_In. 



Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


B 


E3 


B_Out, A_Out, x3, 
A_In, B_In 


B (dans A) 


Nous avons deja considere l'arrivee de E5 dans l'etat B : 


Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


B 


E5 


B_Out, C_In 


C (dans A) 



Attention, il y a un piege ! Dans l'etat C, l'evenement E3 fait d'abord sortir de 
l'etat C et declenche C_Out, puis fait sortir du super-etat A et declenche A_Out, 
declenche ensuite x3, puis fait entrer dans le super-etat A et declenche A_In, 
enfm fait rentrer dans l'etat B (car e'est le sous-etat initial !) et declenche B_In. 



Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


C 


E3 


C_Out, A_Out, x3, 
A_In, B_In 


B (dans A) 


Dans l'etat B, l'evenement E2 fait d'abord sortir de l'etat B et declenche 
B_Out, puis du super-etat A et declenche A_Out, et declenche enfm x2. 


Etat de depart 


Evenement 


Effets 


Etat d'arrivee 


B 


E2 


B_Out,A_Out,x2 
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Concepts de base du diagramme d'activite 




EXERCICE 6-10. 

Recette de cuisine ! 



Recette simplifiee : commencer par casser le chocolat en morceaux, puis le faire fondre. 
En parallele, casser les oeufs en separant les blancs des jaunes. 
Quand le chocolat est fondu, ajouter les jaunes d'ceuf . 
Battre les blancs en neige jusqu'a ce qu'ils soient bien fermes. 
Les incorporer delicatement a la preparation chocolat sans les briser. 
Verser dans des ramequins individuels. 

Mettre au frais au moins 3 heures au refr igerateur avant de servir. 

Representez par un diagramme d'activite la recette de la mousse au chocolat... 

Proposez une version simple, puis completez-la en ajoutant soit des flots 
d'objets explicites soit des input et output pins. 

O Le diagramme d'activite simple est donne par la figure suivante. 

Notez l'utilisation des barres d'embranchement (fork) et de jointure (join), 
permettant de representer precisement le parallelisme dans les flots de con- 
trole de l'activite. 



Notez egalement l'utilisation du nouveau symbole graphique UML 2 pour 
Taction « Attendre 3h » qui est de type : accept time event. 
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ad Mousse au chocolat (simple) 




Aj outer les 
jaunes au 
chocolat fondu 



Verser 
dans des 
ramequinsy 



Casser les oeufs 

et separer les 
blancs des jaunes 





Melanger les 
blancs a la 
preparation 
chocolat 




Recette 
re u ssi e 



Figure 6-25. 

Exemple de diagramme d'activite simple 

Nous allons maintenant completer ce diagramme en ajoutant des flots 
d'objets, comme illustre sur la figure suivante. 
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A retenir FLOTS DE CONTROLE ET FLOTS D'OBJETS 

UML 2 a unifie la notation des flots de controle et des flots d'objets. 

Les flots de controle connectent des actions pour indiquer que Taction 
pointee par la fleche ne peut pas demarrer tant que Taction source 
n'est pas terminee. 

Les flots d'objets connectent des noeuds d'objets pour fournir des entrees 
(inputs) aux actions. Le nom d'un etat peut etre mis entre crochets et 
place avec le nom du type. 



ad Mousse au chocolat 




Faire fondre 
le chocolat 



Casser les oeufs et 
separer les blancs 
des jaunes 



Chocolat 

[fo n d u ] 



v 




Bla 


ICS 


\ 


/ 



Aj outer les 
jaunes au 
chocolat fondu 



4^ 



Battre les 
blancs en 
neige 




Blancs 

[en neige] 



Recette 
re u ssi e 



A 



V 



Melanger les 
blancs a la 
preparation 
chocolat 



Verser 
^ | dans des 
ramequin: 



Mettre au 
refrigerateur 



> 



Attendre 
3h 



Figure 6-26. 

Exemple de diagramme d'activite avec flots d'objets 
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A retenir DEUX NOTATIONS POUR LES FLOTS D'OBJETS 

UML 2 propose deux notations equivalentes pour les flots d'objets. 

Nous avons vu la premiere sur la figure precedente (6-26). Une autre 
notation possible consiste a indiquer les valeurs d'entree a la disposition 
de Taction et celles qu'elle fournit en sortie sous la forme de petits carres 
appeles pins. Le nom du noeud objet est specific: a proximite du pin. 



ad Notations equivalentes 



Actio 



Actioni 



Objectl 



„1 ^ 



Objectl 



Action2 



Objectl 



Action2 



Figure 6-27. 

Notations des flots d'objets 



Si Ton applique cette deuxieme notation a la recette de mousse au chocolat, on aboutit 
au diagramme de la figure suivante (6-28). 
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ad Mousse au chocolat (avec pins) 



f 




Rassembler 
les ingredients 



oeufs 




oeufs 



morceaux de chocolat | | 
morceaux de chocolat 



Casser les oeufs 

et separer les 
blancs des jaunes 



chocolat fondu 




blancs 



Fa ire fond re 
le chocolat 



chocolat fond 



jaunes 



Aj outer les 
jaunes au 
chocolat fondu 



~j blan cs 



Battre les 
blancs en 
neige 



melange chocolate 




blancs en neige 



melange chocolate 



blancs en neige 



Verser 
dans des 
ramequins 



■C 



mousse au 
chocolat 



Melangerles blancs 
a la preparation 
chocolat 



Mettre au 
refrigerateur 



Attend re 
3h 



Recette 
reussie 



Figure 6-28. 

Exemple de diagramme d'activite avec input et output pins 
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Concepts avances du diagramme d'activite 




EXERCICE 6-11. 

Region d'expansion 



Precisez le diagramme d'activite precedent en introduisant une region 
d'expansion pour mieux expliquer la boucle sur le remplissage des ramequins... 



Une region d'expansion est un nceud d'activite structure qui 
s'execute une fois pour chaque element dans une collection 
d' entree. Les entrees et sorties de la collection (nceuds d'expan- 
sion) sont materialises sur la frontiere de la boite par des petits 
rectangles divises en plusieurs compartiments. 



Nous allons utiliser ce nouveau concept UML 2 pour decrire le remplissage 
O successif des ramequins en fonction de la quantite de melange chocolat pro- 
vT* duit. La partie du diagramme modifiee est representee sur la figure suivante. 



A retenir 



REGION D'EXPANSION 




Figure 6-29. 

Exemple de region 
d'expansion 




Melanger les 
blancs a la 
preparation 



chocolat 



\/ Melange 



Iterative 




Ramequins 



Mettre au 
refrigerateur 
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EXERCICE 6-12. 

Region d'expansion et flot d'exception 



Precisez maintenant le debut du diagramme d'activite de la figure 6-26 en 
introduisant une region d'expansion pour mieux expliquer la separation des 
blancs des jaunes ainsi qu'un flot d'exception pour prendre en compte I'oubli 
du chocolat sur le feu... 



Nous avons vu a la question precedente comment utiliser la region d'expan- 
O sion. Notez egalement le nouveau symbole UML 2 du nceud final de flot (flow 
vT* final), permettant d'exprimer le fait que si le cuisinier rate la separation du 

jaune et du blanc, il ne remplit pas les nceuds d'expansion de sortie. 

Si nous voulons ajouter l'exception possible consistant a laisser bruler le cho- 
colat pendant qu'on s'occupe des oeufs, il faut introduire le concept de region 
interruptible et de Hot d'exception. 



Une region interruptible est un ensemble de nceuds et d'arcs d'activite 
au sein duquel I'activite se termine si I'evenement designe se produit. 
Cet evenement d'interruption apparait comme une fleche « eclair » 
partant de I'interieur de la region interruptible et se dirigeant vers la 
bordure du gestionnaire d'interruption. 



A retenir 



REGION INTERRUPTIBLE 



La figure suivante illustre 1' utilisation de ces nouveaux concepts UML 2 en 
montrant le diagramme d'activite complet. 
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ad Mousse au chocolat (exception) 










/ 



Casser I'oeuf et separer 
le blanc du jaune 




Recette 
re u ssi e 



Figure 6-30. 

Diagramme d'activite complete de la recette de mousse au chocolat 



Conseils methodologiques 



CONTEXTE DYNAMIQUE 



Pour representer le contexte dynamique, utilisez un diagramme de communication, de la 
facon suivante : 
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• le systeme etudie est represente par un objet au centre du diagramme ; 

• cet objet central est entoure par une instance de chaque acteur ; 

• un lien relie le systeme a chacun des acteurs ; 

• sur chaque lien sont repertories tous les messages en entree et en sortie du sys- 
teme, sans numerotation. 

COMMENT CONSTRUIRE LES DIAGRAMMES D'ETATS ? 

Pour construire efncacement les diagrammes d'etats : 

• representez d'abord la sequence d'etats qui decrit le comportement nominal d'une 
instance, avec les transitions associees ; 

• ajoutez progressivement les transitions qui correspondent aux comportements 
« alternatifs » ou d' exception ; 

• completez les effets sur les transitions et dans les etats ; 

• structurez le tout en sous-etats et utilisez les notations avancees (entry, exit, 
etc.) si le diagramme devient trop complexe. 

EVENEMENTS 

Distinguez bien les evenements internes (« when(condition) ») et temporels 
(« after(duree) ») de ceux qui resultent de la reception de messages. 

Attention : un evenement (comme une transition) est par convention instantane, ou en 
tout cas insecable (atomique). II est done tout a fait incorrect de tester sa duree ! Les 
seuls concepts dynamiques en UML qui possedent la notion de duree sont l'etat et l'acti- 
vite durable. 

SUPER-ETAT 

Pensez a utiliser le concept de super-etat pour factoriser les nombreuses transitions 
declenchees par le meme evenement et amenant au meme etat. 

EFFET ET CONDITION 

Attention, sur une transition, l'effet est toujours declenche apres 1'evaluation de la 
condition de garde. 

TRANSITION AUTO M ATI QUE 

Utilisez correctement les transitions automatiques. Une activite durable a l'interieur d'un 
etat peut etre soit : 

• « Continue » : elle ne s'arrete que lorsque se produit un evenement qui fait sortir 
de l'etat ; 
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• « Finie » : elle peut egalement etre interrompue par un evenement, mais s'arrete 
de toute fa9on d'elle-meme au bout d'un certain temps, ou quand une certaine 
condition est remplie. 

La transition de completion d'une activite durable, aussi appelee transition automatique, 
est representee en UML sans nom d'evenement ni mot-cle. 

TRANSITION PROPRE OU INTERNE ? 

Retenez bien la difference entre la transition propre et la transition interne : 

• Dans le cas d'une transition propre, l'objet quitte son etat de depart pour y revenir 
ensuite. Cela peut avoir des consequences secondares non negligeables comme l'inter- 
ruption puis le redemarrage d'une activite durable, la realisation d'effets en entree 
(« entry ») ou en sortie (« exit ») de l'etat, etc. ; en outre, si l'etat est decompose en 
sous-etats, une transition propre ramene forcement l'objet dans le sous-etat initial. 

• En revanche, la transition interne represente un couple (evenement/effet) qui n'a 
aucune influence sur l'etat courant. La transition interne est notee graphiquement 
a l'interieur du symbole de l'etat. 

PSEUDO-ETAT « HISTORY » 

II faut savoir utiliser a bon escient le pseudo-etat « history » : il permet a un super- 
etat de se souvenir du dernier sous-etat sequentiel qui etait actif avant une transition 
sortante. Une transition vers l'etat « history » rend de nouveau actif le dernier 
sous-etat actif, au lieu de ramener vers le sous-etat initial. 

EFFETS D'ENTREE ET DE SORTIE 

N'abusez pas des effets d'entree et de sortie. En effet, en cas de modification de l'effet 
sur une des transitions concernees, il vous faudra penser a « defactoriser » et a remettre 
l'effet sur chaque autre transition. Un effet d'entree (ou de sortie) doit reellement etre 
une caracteristique de l'etat dans lequel il est decrit et pas seulement un artifice local de 
factorisation. 

ACTION D'ENVOI DE MESSAGE 

N'oubliez pas de decrire dans vos diagrammes d'etats Taction importante qui consiste a 
envoyer un message a un autre objet sur declenchement d'une transition. La syntaxe de 
cette action particuliere est la suivante : « I send cible.message ». 

ETATS CONCURRENTS 

Si un objet realise plusieurs comportements relativement independants, il y a deux 
facons de le modeliser : 
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• considerer qu'il contient en fait plusieurs objets et que chacun d'entre eux realise 
un de ses comportements, et representer cela au moyen d'une classe structuree 
dans un diagramme de structure composite (ou un composant dans un diagramme 
de composants) ; 

• decrire des « regions concurrentes » au sein du diagramme d'etats ; l'etat courant 
devient alors un vecteur a plusieurs lignes qui peuvent evoluer en parallele. 

COMMENT ENRICHIR LES CLASSES A PARTIR DES DIAGRAMMES D'ETATS ? 

Des regies simples permettent d'enrichir la definition des classes a partir des 
diagrammes d'etats : 

• les operations publiques correspondent aux noms des messages emis par les 
acteurs ; 

• les operations privees correspondent aux noms des messages envoyes a soi- 
meme ; 

• les attributs correspondent aux noms des donnees remanentes, manipulees dans 
les actions, les activites ou les conditions. 

OPERATION ET ACTEUR ? 

Le concept d'operation n'a pas de sens sur un acteur humain : on ne cherche generale- 
ment pas a le modeliser d'une facon deterministe. Sur un acteur non-humain, en 
revanche, la liste des operations represente son interface (au sens d'une API par 
exemple), telle qu'elle est utilisee par le systeme etudie. Cela s'avere particulierement 
utile pour verifier l'interoperabilite des deux systemes et s'assurer que ces operations 
sont deja disponibles, ou prevues dans les specifications. 

PAS DE DIAGRAMME D'ETATS A MOINS DE TROIS ETATS ! 

Pas de diagramme d'etats si Ton compte moins de trois etats ! Ne perdez pas de temps a 
dessiner des diagrammes d'etats qui ne contiennent que deux etats (de type « on/off »), 
voire un seul. Dans ce cas, la dynamique de la classe est surement simple et susceptible 
d'etre apprehendee directement. En suivant cette regie, il apparait que 10 % des classes 
necessitent usuellement une description detaillee sous forme de diagramme d'etats. 

FAUT-IL UTILISER TOUTES LES SUBTILITES DU DIAGRAMME D'ETATS ? 

Ne mettez pas forcement en ceuvre toutes les subtilites des diagrammes d'etats. Le 
formalisme du diagramme d'etats UML est tres puissant, mais aussi tres complexe. Le 
lecteur qui n'en maitrise pas tous les details risque fort de ne pas vous suivre. 
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Ce chapitre va nous permettre de mener une etude de cas 
complete partant de la modelisation metier et aboutissant a 
la conception detaillee (cibleJava ou C#), en passant par 
I'expression des besoins fonctionnels et I'analyse orientee 
objet. 

Nous allons voir en particulier : 

•Quels diagrammes d'UML utiliser pour la modelisation 
metier ? 

• Comment se servir de cette modelisation metier pour 
mieux definir les besoins informatiques ? 

• Comment I'analyse linguistique permet d'aider a la mode- 
lisation du domaine ? 

• Comment decrire une architecture en couches avec UML ? 

•Comment utiliser les diagrammes de sequence et de de 
communication pour decrire les interactions entre objets 
informatiques, et repartir les operations ? 

• Comment repercuter les decisions d'affectation des res- 
ponsabilites aux objets dans les diagrammes de classes ? 

•Comment traduire les diagrammes UML de conception 
detaillee en code oriente objet ? 
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Etape 1 - Model isation metier [business modeling) 



Dans le cadre de 1'amelioration qu'elle veut apporter a son systeme d'information, une 
entreprise souhaite modeliser, dans un premier temps, le processus de formation de ses 
employes afin que quelques-unes de leurs taches soient informatisees. 

1 . Le processus de formation est initialise lorsque le responsable formation regoit une 
demande de formation de la part d'un employe. Cette demande est instruite par le 
responsable qui la qualifie et transmet son accord ou son disaccord a l'interesse. 

2. En cas d'accord, le responsable recherche dans le catalogue des formations agreees 
un stage qui correspond a la demande. II informe l'employe du contenu de la forma- 
tion et lui propose une liste des prochaines sessions. Lorsque l'employe a fait son 
choix, le responsable formation inscrit le participant a la session aupres de l'orga- 
nisme de formation concerne. 

3. En cas d'empechement, l'employe doit informer le responsable de formation au plus 
tot pour annuler l'inscription ou la demande. 

4. A la fin de sa formation, l'employe doit remettre au responsable formation une appre- 
ciation sur le stage qu'il a effectue, ainsi qu'un document justifiant de sa presence. 

5. Le responsable formation controle par la suite la facture que l'organisme de formation 
lui a envoy ee avant de la transmettre au comptable achats. 



A retenir 


STEREOTYPES POUR LA MODELISATION METIER 

En matiere de modelisation metier, Jacobson 3 a ete le premier a 
proposer d'utiliser les concepts UML d'acteur, cas d'utilisation, classe, 
package, etc., avec des stereotypes particuliers. Dans la suite de I'exer- 
cice, nous utiliserons les stereotypes suivants, fournis entre autres par 
Rational/Rose : 

Figure 7-1. Cas d'utilisation f J\ 




Stereotypes Utilises stereotype, appele // 

processus metier 

pour la modelisation 

Processus metier 

metier 

Acteur stereotype, 






representant une ""^s. 




entite externe a 3^ 




1' entreprise 




Acteur metier 



a. Software Reuse: I. Jacobson et at, 1997, Prentice Hall, puis The Unified Software Development Process, 
I. Jacobson, G. Booch, J. Rumbaugh, 1999, Addison-Wesley (qui existe en version francaise chez Eyrolles : Le 
processus unifie de developpement logiciel). 
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A retenir Figure 7-1. 

(suite) 



Class e stereo typee 
representant un humain 
agissant a 1 1 interieur 
de l'entreprise 



Classe stereo typee 
representant une entit< 
passive manipulee par 
un travailleur metier 



Package stereotype, 
structurant le 
modele metier 



Travailleur metier 




Entite metier 




Unite d'organisation 



Exercice 7-1. 

Modelisation d'un processus metier 

Utilisez les stereotypes pour la modelisation metier afin de montrer le processus de 
formation et ses acteurs sur un diagramme de cas d'utilisation. 

Modelisez le processus de formation et ses acteurs. 



O Le processus de formation est represente par un cas d'utilisation stereotype. 

^ Les acteurs impliques sont (dans l'ordre de l'enonce) : 

• 1' employe ; 

• le responsable formation ; 

• l'organisme de formation ; 

• le comptable des achats. 
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Seul l'organisme de formation est une entite externe a l'entreprise, ce qui 
donne le schema suivant : 





EXERCICE 7-2. 

Le diagramme d'activite pour modeliser un processus 



Decrivez la dynamique du processus de formation au moyen d'un diagramme d'activite. 
Utilisez des partitions verticales pour affecter les responsabilites aux acteurs. 



Modelisez le processus de formation avec un diagramme d'activite. 



Le processus de formation comporte un ensemble d'actions ordonnees dans 
O le temps et affectees a un des acteurs identifies precedemment. Cet enchaine- 
ment se represente parfaitement grace a un diagramme d'activite. 

Les partitions 1 permettent d'agencer graphiquement les actions de telle sorte 
que celles qui sont affectees a un meme acteur se trouvent dans la meme 
bande verticale. 



1 . Generalisation UML 2 du concept de « swimlane ». 
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Pour completer le diagramme, on peut egalement ajouter la creation et le change- 
ment d'etat des entites metier, suite a la realisation des actions. 

Notez que nous n'avons pas utilise l'icone specifique de l'entite metier pour la 
DemandeDeFormation, ann de pouvoir plus facilement indiquer ses changements 
d'etats entre crochets. 

Le diagramme ainsi obtenu est tres interessant, puisqu'il fait le pont entre les trois 
axes de modelisation : fonctionnel (actions), dynamique (Hots) et statique (entites et 
partitions) ! 
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: Employe 



: Responsible formation 



: Oigjnisme de formation 



Demand* DeFormation 
[AR«r«« Instruction] 



Demand* D* Formation 




■Q a 



"Q 




Figure 7-4. 

Diagramme d'activite complete du processus de formation 



Etape 2 - Definition des besoins du systeme informatique 



Poursuivons notre etude fonctionnelle. La definition des taches qui seront informatisees 
est realisee par selection de certaines actions du modele metier. Nous allons ainsi 
deduire le carrier des charges fonctionnel du systeme informatique a partir de l'etude 
precedente, et en particulier du diagramme d'activite. 

Le systeme doit permettre d'initialiser une demande de formation et de suivre cette 
demande jusqu' a l'inscription effective d'un employe. 
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Le systeme de gestion des demandes de formation doit done permettre d'automatiser les 
actions metier suivantes : 

• Rediger une demande (employe) ; 

• Instruire une demande (responsable formation) ; 

• Chercher un stage (responsable formation) ; 

• Selectionner une session (employe) ; 

• Commander un stage (responsable formation). 

Et il ne faut pas oublier qu'un employe a la possibilite d'annuler une demande ou une 
inscription a une session. 

Pour tout cela, il est indispensable que le systeme informatique gere un catalogue de 
formations agreees auquel les employes peuvent acceder partiellement en lecture, et le 
responsable formation globalement en ecriture. Ce catalogue contiendra non seulement 
le contenu technique, la duree, etc., des formations proposees par les organismes agrees, 
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mais aussi les dates et lieux des prochaines sessions. Le responsable formation pourra 
egalement creer des regroupements de formations appeles themes. 



EE 



EXERCICE 7-3. 

Le diagramme de cas d'utilisation pour definir les besoins 
informatiques 

Elaborez le diagramme de cas d'utilisation du systeme informatique de gestion des 
demandes de formation. Ecrivez quelques lignes de resume pour chaque cas d'utilisation. 

Elaborez le modele des cas d'utilisation du systeme. 



O 



O Les acteurs impliques sont (dans l'ordre de l'enonce) : 

• 1' employe ; 

• le responsable formation ; 

• l'organisme de formation. 

En effet, les actions du comptable ne seront pas informatisees et il n'interagira 
done pas directement avec le systeme informatique. 

D'apres la liste des actions metier, on peut definir les cas d'utilisation 
suivants : 



Demander une formation 

L' employe peut consulter le catalogue et selectionner un theme, ou une for- 
mation, ou meme une session particuliere. La demande est automatiquement 
enregistree par le systeme et transmise au responsable formation par e-mail. 



Traiter les demandes 

Le responsable formation va utiliser le systeme pour indiquer aux employes 
sa decision (accord ou refus). En cas d'accord sur une session precise, le sys- 
teme va envoyer automatiquement par fax une demande d'inscription sous 
forme de bon de commande a l'organisme concerne. Si l'employe n'a pas 
choisi une session, mais simplement une formation ou un theme, le responsa- 
ble formation va consulter le catalogue et selectionner les sessions qui parais- 
sent correspondre le mieux a la demande. Cette selection sera transmise par 
e-mail a l'employe, qui pourra ainsi faire une nouvelle demande plus precise. 
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Gerer ses demandes 

L' employe peut consulter l'etat de ses demandes de formation en cours et 
eventuellement les annuler individuellement. II peut egalement preciser une 
demande incomplete. Le responsable formation est automatiquement averti 
par e-mail. 



Mettre a jour le catalogue 

Le responsable formation peut introduire une nouvelle formation dans le 
catalogue, modifier une formation existante ou supprimer une formation 
qu'un organisme a abandonnee. II peut egalement modifier les regroupements 
de formations qui ont ete faits par themes. II a aussi la possibilite de mettre a 
jour les dates et lieux des sessions. 

Le diagramme preliminaire ci-apres synthetase toutes ces reflexions. 
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EXERCICE 7-4. 

Description essentielle d'un cas d'utilisation 

Redigez une description detaillee essentielle de Mettre a jour le catalogue. 
Dessinez un diagramme de sequence representatif pour ce cas d'utilisation. 



J" 

O 



on 



Sommaire d'identification 

Titre : Mettre a jour le catalogue Type : essentiel detaille 

Resume : le responsable formation est charge de la mise a jour continue 
d'un catalogue qui repertorie les formations agreees disponibles pour les 
employes. La plupart des modifications proviennent des organismes de 
formation. 



Acteurs : Responsable formation. 

Date de creation : 28/09/04 
Version : 3.0 



Date de mise a jour : 26/06/06 
Responsable : Pascal Roques 



Description des enchamements 

Preconditions : le responsable formation s'est authentifie sur le systeme. 

Postconditions : une nouvelle version du catalogue est disponible en 
consultation. 

Scenario nominal : 



1. Ce cas d'utilisation commence en 
general quand un Organisme de for- 
mation informe le Responsable for- 
mation de modifications par rapport 
a son offre. 



2. Le Responsable formation peut intro- 
duire une nouvelle formation dans le 
catalogue, modifier une formation 
existante ou enlever une formation 
supprimee par l'organisme. 

Lors d'une creation ou d'une modifi- 
cation, le Responsable formation a la 
possibilite de modifier 1' agenda des 
sessions prevues pour la formation. 



3. Le Systeme previent les utilisateurs 
connectes qu'ils risquent de tra- 
vailler sur une version obsolete. 



Lors d'une suppression, le Systeme 
indique au Responsable formation la 
liste des participants qui etaient ins- 
crits aux sessions annulees, et les 
inscriptions sont annulees. 
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4. Le Responsable formation valide ses 
modifications. 



5. Le Systeme previent les employes 
connectes qu'une nouvelle version 
du catalogue est disponible. 



Sequences alternatives : 

Al : informations incompletes 

L'enchamement Al demarre a l'etape 2 du scenario nominal. 

2. Lorsque les informations relatives a une nouvelle formation sont incom- 
pletes (par exemple, absence de date de session), la formation est mise au 
catalogue mais aucune inscription ne pourra etre prise. La description 
doit etre modifiee et completee plus tard. 

Le scenario nominal continue a l'etape 2. 

A2 : gestion des themes 

La sequence A2 demarre a l'etape 2 du scenario nominal. 

2. Le responsable formation peut commencer par creer un nouveau theme 
ou renommer un theme existant. II peut egalement deplacer une formation 
d'un theme a un autre. 

Le scenario nominal continue a l'etape 2. 



Specifications supplementaires 

Concurrence : ce cas d'utilisation ne peut etre execute que par un responsable 
a la fois. 

Disponibilite : le catalogue est accessible via l'lntranet du lundi 9 h au ven- 
dredi 17 h. Les actions de maintenance doivent etre limitees au strict mini- 
mum pendant ces heures. 



Exemple de diaqramme de sequence systeme du cas d'utilisation : 
« Mettre a jour le catalogue ». 

Nous avons utilise un fragment de type alternatives (alt) pour indiquer que 
les actions effectuees par le Responsable formation peuvent arriver dans 
n'importe quel ordre. Ce fragment alternatives est lui-meme imbrique dans 
une boucle (loop). 
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Figure 7-7. 

Diagramme 
de sequence 
systeme ducas 
d' utilisation : 
Mettre a jour 
le catalogue 



sd DSS Mettre a jour le catalogue 



:Resp. formation 



« systems 

:SGDF 



loop 



alt / 

[creation] 



creerFormation() 



opt 



ere e rCa I e n d ri e rS e ssi o n s() 



[ajoutSession] 



choisirFormation{} 



ijouterSession() 



[suppression Session] „u„i„i.c„™ „*i„„n 
L ^ i J cnoisirFormationQ 



annulerSession() 



inscrits : Em ploye 



annulation session 



> 



□ 



Remarquons que les employes inscrits a une session annulee sont automati- 
quement avertis par le systeme (e-mail). La fleche du message « annulation 
session » est ouverte pour indiquer qu'il s'agit d'un message asynchrone 2 . 



A retenir FLOTS DE CONTROLE DES MESSAGES 

Un flot de controle synchrone signifie que I'objet emetteur se bloque en 
attendant la reponse du recepteurdu message. 

Dans un flot de controle asynchrone au contraire, I'objet emetteur 
n'attend pas la reponse du recepteur et poursuit sa tache sans se 
soucier de la reception de son message. 



II faudra done ajouter un acteur secondaire a notre diagramme de cas d' utili- 
sation preliminaire. 



2. Attention, ceci est conforme a la nouvelle norme UML 2. Dans les versions precedentes, le message asynchrone etait 
represente par une demi-fleche ouverte. 
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EXERCICE 7-5. 

Amelioration du diagramme de cas d'utilisation 



Ameliorez le diagramme de cas d'utilisation preliminaire du systeme informatique 
de gestion des demandes de formation. 

En particulier, pour demander une formation et pour maintenir le catalogue, le 
systeme doit proposer une fonctionnalite de base de consultation du catalogue. 

Ameliorez le modele des cas d'utilisation du systeme. 



Pour demander une formation, le systeme doit proposer une fonctionnalite de 
O base de consultation du catalogue. L'employe peut consulter le catalogue sans 
vT* faire de demande.. La creation d'une demande vient etendre optionnellement 

la consultation 3 . 

L'acteur « Organisme de formation » ne fait que recevoir des messages venant 
du systeme, nous utiliserons done une association unidirectionnelle. De meme, 
l'employe est acteur secondaire (recepteur) des cas d'utilisation du responsable 
formation et reciproquement. 

De plus, un responsable formation peut egalement effectuer une demande de 
formation, etc. Nous ajoutons done une relation de generalisation entre acteurs. 

Enfin, pour ne pas surcharger le diagramme, nous n'y representerons pas le 
processus d'identification de l'employe ou du responsable formation. Mais 
nous creerons plutot un package different. Le modele de cas d'utilisation est 
ainsi divise en deux packages : 

• cas d'utilisation operationnels ; 

• cas d'utilisation de support. 

Le diagramme de cas d'utilisation du premier package devient : 



3. 



On pourrait egalement argumenter que pour demander une formation, il faut obligatoirement consulter le catalogue, ce 
qui pourrait justifier une relation d'inclusion (« include ») entre cas d'utilisation. Nous voyons la une fois de plus la dif- 
ficulte (et le danger) des relations entre cas d'utilisation ! 
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Figure 7-8. 

Diagramme de cas d 'utilisation 
du package des cas operationnels 




Celui du second package est fourni par la figure suivante. 



Figure 7-9. 

Diagramme de cas d'utilisation du 
package des cas de support 



ud Support ^ 




S 


f 


/ « support" \ 






V S'authentifier J 


Employe 




L 


k 




Resp. formation 





EXERCICE 7-6. 

Diagramme de contexte statique 

La contrainte de concurrence sur ce cas d'utilisation amene une derniere question. 
Elaborez le diagramme de contexte statique du systeme. 
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J- 

O 



on 



Le systeme de gestion des demandes de formation est fondamentalement 
multi-utilisateurs (typiquement : un intranet) , sauf pour le responsable forma- 
tion qui doit en etre le seul utilisateur en modification a un moment donne. 

Les organismes de formation n'ont pas acces au systeme : ils ne font que 
recevoir des commandes (une a la fois), ce qui explique la fleche de navigabi- 
lite sur l'association entre le systeme et l'acteur non-humain. 



Figure 7-10. 

Diagramme de contexte statique 

du systeme de gestion 

des demandes de formation 





«system» 
Gestion des demandes 
de formation 



V 



0..1 



«actor» 
Organisme de formation 



Etape 3 - Analyse du domaine (partie statique) 



Nous allons reprendre l'enonce de l'etude de cas, deja traitee du point du vue fonc- 
tionnel aux etapes 1 et 2, en le reformulant et en le simplifiant legerement. 

1 . Le processus de formation est initialise lorsque le responsable formation recoit une 
demande de formation de la part d'un employe. 

2. Cette demande est instruite par le responsable qui qualifie la demande et transmet son 
accord ou son disaccord a l'interesse. 

3. En cas d'accord, le responsable recherche dans le catalogue des formations agreees 
un stage correspondant a la demande. 

4. H informe l'employe du contenu de la formation et lui propose une liste des 
prochaines sessions. 

5. Lorsque l'employe retourne son choix, le responsable formation inscrit le participant 
a la session aupres de l'organisme de formation concerne. 

6. Le responsable formation controle par la suite la facture que lui a adressee l'orga- 
nisme de formation avant de la transmettre au comptable des achats. 

Nous avons deja identifie les travailleurs metier impliques dans le processus de forma- 
tion (exercice 7-1). II nous faut maintenant aborder ce dernier sous Tangle statique qu'il 
presente et decouvrir les principales entites metier. 
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Pour cela, une analyse lexicale du texte de l'enonce est tout a fait indiquee. Cette tech- 
nique est en general sous-utilisee, car elle peut sembler fastidieuse. Elle est pourtant tres 
efficace pour decouvrir des objets candidats dans les cas difficiles, par exemple si le 
modelisateur connait mal le domaine metier. 

EXERCICE 7-7. 

Analyse linguistique (1/6) 

Modelisez la phrase 1, en employant les stereotypes de Jacobson. 



Une analyse simpliste des noms et groupes nominaux fournit les entites 
O suivantes : processus de formation, responsable formation, demande de for- 
mation, employe. Considerons chacun des candidats a tour de role. 

• Processus de formation a deja ete identifie a l'etape 1 en tant que processus 
metier : il n'apparaitra pas sur le diagramme de classes. 

• En revanche, responsable formation et employe y figureront, car ils ont ete 
identifies comme travailleurs metier. 

• Articles « un/une » ou « le/la ». L' article indefini (« un/une ») indique que 
le nom est utilise de facon generique, alors que 1' article defini (« le/la ») 
indique que le nom est unique dans le contexte de la phrase. Attention 
cependant : 1' article « un » signifie souvent « un en general », (comme 
dans : lorsque le responsable formation recoit une demande de formation), 
mais aussi parfois « un et un seul » pour indiquer que le pluriel ne serait pas 
possible (comme dans : de la part d'wn employe). Dans ce cas, on obtient 
une multiplicite 1 sur une association. 

Nous en deduisons aisement le diagramme de classes suivant. 



Figure 7-11. 

Modelisation statique de la phrase 1 




Demande de formation 
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rj - EXERCICE 7-8. 

Analyse linguistique (2/6) 

Modelisez la phrase 2. 

O En procedant, comme pour la premiere phrase, a une analyse simpliste des 
"o noms et groupes nominaux, on obtient les entites suivantes : demande, res- 
vT* ponsable, accord, disaccord, l'interesse. 

• Reference indirecte par « ce/cette », « ces » : une phrase utilisant le mot 
« ce » fait presque toujours reference au sujet de la phrase precedente. Les 
concepts demande et demande de formation sont done identiques. 

• Attention aux synonymes ! II est clair que responsable n'est pas un nou- 
veau concept, mais simplement une forme plus courte de responsable for- 
mation. C'est un peu moins evident avec le mot interesse qui fait reference 
a 1' employe qui a emis la demande. 

• Possessifs : « son/sa », « ses ». Nous pouvons traduire la possession de deux 
facons : une association ou un attribut. Nous choisissons l'association si le 
possesseur et la possession sont tous les deux des concepts. Nous choisissons 
l'attribut si la possession est une simple caracteristique du possesseur. 

• Conjonction de coordination « ou ». Un « ou exclusif » doit faire penser a 
une relation de generalisation/specialisation, mais uniquement si les con- 
cepts specialises ont des attributs et des comportements differents. Dans le 
cas contraire, il vaut mieux introduire un simple type enumere. Dans notre 
exemple, nous pouvons considerer que 1' accord ou le disaccord sont des 
specialisations d'une entite reponse relative a la demande. En effet, le 
disaccord aura probablement un attribut motif contrairement a l'accord. 

• Verbes : la demande est recue par le responsable, puis instruite et enfin 
qualifiee. II n'est pas question de dessiner trois associations pour modeliser 
toutes les actions que le responsable peut effectuer a propos de la demande. 
Au contraire, le diagramme de classes doit representer une vue statique qui 
soit valable a tout moment. Nous renommons done l'association entre 
responsable et demande avec un verbe plus neutre (traiter) , et nous modi- 
fions les multiplicites en consequence. 

Pour completer le diagramme, nous avons suppose qu'un employe ne peut 
pas emettre plus d'une demande a la fois. On notera egalement les multiplici- 
tes entre demande et reponse : une reponse est forcement liee a une et une 
seule demande ; une demande peut exister sans reponse (tant qu'elle n'est pas 
instruite). 
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Figure 7-12. 

Modelisation statique 
de la phrase 2 




Accord Desaccord 



EXERCICE 7-9. 

Analyse linguistique (3/6) 

Modelisez la phrase 3. 

O Une nouvelle analyse rapide des noms et groupes nominaux fournit les entites 
~0 suivantes : accord, responsable, catalogue, formation, stage, demande. 

• Accord, responsable et demande ont ete identifies precedemment. 

• Conteneur et contenu : catalogue est un conteneur compose deformations ; 
les deux peuvent donner lieu a des entites, si elles portent des attributs et 
des comportements. C'est bien le cas dans notre exemple. On doit alors 
etudier la possibilite d'une agregation ou d'une composition. Sinon, le con- 
tenu peut etre un simple attribut du conteneur. 

• Pluriel : le pluriel sur un nom (catalogue des formations) donne souvent lieu a 
une entite au singulier, mais avec une multiplicite « 0..* » sur une association. 

• Verbes : attention, les verbes correspondent souvent a des actions effectuees 
sur les entites (le responsable recherche...). Ces actions ne se traduisent 
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generalement pas dans le diagramme de classes d'analyse. Elles donnent en 
revanche des indications sur la dynamique, et peuvent donner lieu a des 
fragments de diagramme de sequence ou de communication. 



Figure 7-13. 

Fragment de modele dynamique 
issu de la phrase 3 



: Responsable formation 




• Adjectifs : ils represented soit des attributs d'une entite deja identifiee, soit une 
possibilite de relation de generalisation. Attention : ils peuvent aussi simple- 
ment ajouter du « bruit » dans le texte, comme dans notre cas ou seules les for- 
mations agreees ont une existence notable dans le processus de formation. 

• Participes presents : ils indiquent souvent une association entre deux 
entites. Par exemple, « un stage correspondant a la demande » amene la 
creation d'une association entre les entites stage et demande. 

• Attention aux synonymes ! Pour eviter les repetitions qui alourdissent le 
style, 1' usage des synonymes est frequent : formation et stage en sont une 
bonne illustration. Le modelisateur doit debusquer ces synonymes et les 
« reduire » en choisissant un nom principal d'entite. Nous prefererons le 
terme formation plutot que celui de stage. 

Toute cette discussion conduit au diagramme de classes ci-apres. 



Figure 7-14. 

Modelisation statique de la phrase 3 



La meme formation 
peut satisfaire un 
nombre quelconque 
de demandes 





Catalogue 



Composition 



est satisfaite par 



0..' 



0.1 




Demande de formation 



Formation 
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EXERCICE 7-10. 

Analyse linguistique (4/6) 

Modelisez la phrase 4. 

O Une analyse sommaire des noms et groupes nominaux permet de relever les 
~0 entites suivantes : employe, contenu, formation, liste, session. 

• Reference indirecte par un pronom : « il/elle », etc. Les pronoms sont des 
references a un autre nom qui est souvent le sujet de la phrase precedente. 
Ici, « il informe. . . » concerne de toute evidence le responsable. 

• Employe et formation ont ete identifies precedemment. 

• Contenance ou possession : entite a part entiere ou attribut suivant les cas. Si 
Ton considere qu'une formation a un contenu dont la structure est complexe 
(prerequis, objectifs, plan detaille, etc.) et un comportement, il est tout a fait 
justifie d'en faire une entite. Comme nous l'avons souligne precedemment, 
on doit etudier la possibilite d'une agregation ou d'une composition. 

• Conteneur : le mot liste indique simplement une multiplicite « * » et 
apporte souvent une notion d'ordonnancement (contrainte UML 
{ordered}). II ne faut surtout pas identifier une entite liste lors de la 
phase d' analyse : le choix des types de conteneur est vraiment du ressort de 
la conception detaillee, voire de 1' implementation. 

• Attention aux faux synonymes ! Cette fois-ci, il ne faut pas croire que ses- 
sion est synonyme deformation ou stage. En effet, le concept de session 
ajoute des notions de date et de lieu qui ne font pas partie du concept plus 
generique de formation. On peut evoquer les merites de la « formation 
UML de 4 j proposee par Valtech Training », et s'inscrire a la « session qui 
a lieu a Toulouse du 9 au 19 mai 2005 ». De plus, ces entites ont des com- 
portements bien distincts : on peut reporter ou annuler une session, sans 
modifier de quelque maniere que ce soit la formation. 

• Verbes : la encore, les verbes represented des echanges de messages entre 
instances, et absolument pas des associations. 
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Figure 7-15. 

Fragment de modele dynamique 
issu de la phrase 4 




: Responsable formation 



: Employe 



..inf orme.. 



..propose... 



contenu de la formation 



liste des prochaines sessions 



Le resultat de ces cogitations est synthetase sur le schema presente ci-apres. 



Figure 7-16. 

Modelisation statique 
de la phrase 4 




Formation 
1 - \ 1 



donne lieu a 




Contenu 



Modelisation 
du mot 
"liste" 




Session 



a 



La relation entre formation et session est une nouvelle illustration de I'important « pattern 
de la metaclasse », etudie au chapitre 3, exercice 3-11. 




EXERCICE 7-11. 

Analyse linguistique (5/6) 



Modelisez la phrase 5. 

Une fois encore, 1' analyse linguistique nous fournit les entites candidates : 
O employe, choix, responsable formation, participant, organisme de formation. 

• Employe, responsable et organisme de formation ont ete identifies 
precede mment. 

• Une nouvelle fois, il faut veiller a ne pas modeliser un comportement 
dynamique dans le diagramme de classes ! La phrase 5 se traduirait directe- 
ment par le fragment de diagramme de sequence suivant. 
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Figure 7-17. 

Modelisation dynamique 
de la phrase 5 

: Organisme 

: Employe : Responsable formation de formation 



: Choix 


trans formation 
d'un verbe 
/ en message 

inscription (session, employe) 
^ 


> 





• Verbes : souvent le verbe cache un nom ! Dans l'exemple precedent, ou « le 
responsable formation inscrit le participant », le diagramme de sequence fait 
apparaitre un message inscription qui porte des parametres. En fait, nous avons 
besoin d'une entite inscription qui represente une sorte de contrat entre le 
responsable et 1'organisme externe. Cette entite porte des attributs (date, prix, 
etc.) et des comportements (reporter, annuler, etc.). Nota - Les entites de type 
contrat se modelisent tres frequemment comme des classes d'association. 

• Termes vagues : le mot choix est delicat a modeliser. En effet, il s'agit d'un 
mot imprecis, d'un terme vague. II faut done le situer dans le contexte 
auquel il se rapporte. D'apres la phrase 4, l'employe choisit une des ses- 
sions proposees par le responsable. Le mot choix dans ce contexte ne sert 
qu'a identifier une session particuliere pour laquelle le responsable va faire 
une demande d'inscription aupres de 1'organisme de formation. II ne s'agit 
done pas d'une nouvelle entite, mais plutot d'un role joue par une session 
dans une relation avec une inscription. 

• Roles : il faut veiller a ne pas creer systematiquement de nouvelles entites. 
En effet, certains noms representent simplement des roles joues par des 
entites deja identifiees. C'est le cas pour participant, qui ne decrit qu'un 
role joue par un employe dans le cadre d'une session. 

• Acteurs. Faut-il relier organisme deformation a session ? C'est ce que sem- 
ble indiquer la phrase 5. Toutefois, nous avons vu avec la phrase 4 que les 
sessions se rapportent toutes a une formation. II est done plus judicieux de 
relier directement organisme de formation & formation. 

La modelisation statique de la phrase 5 est illustree sur la figure suivante. 




Etude de cas complete : de la modelisation metier a la conception detaillee en Java ou C# 



Chapitre 7 



233 




EXERCICE 7-12. 

Analyse linguistique (6/6) 

Modelisez la phrase 6. 

Pour cette derniere phrase aussi, 1' analyse linguistique nous fournit les entites 
"o candidates : responsable formation, suite, facture, organisme de formation, 
vf* comptable des achats. 

• Responsable formation et organisme de formation ont ete identifies prece- 
demment. Comptable des achats est un travailleur metier comme nous 
l'avions indique a l'etape 1. 

• Propositions temporelles : elles ne servent que pour la modelisation 
dynamique. Dans notre cas, « controle par la suite... » ne fait qu'indiquer 
une succession temporelle de messages. Elle permet implicitement de relier 
la facture a V inscription (voir phrase 5). 
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EXERCICE 7-13. 

«1» Modele metier - decoupage en packages 



Rassemblez tous les fragments precedents sur un meme diagramme de classes. 

Proposez une decoupe du modele en packages representant des unites d'organisation 
metier. 



Elaborez un diagramme de classes global montrant un decoupage en packages. 



^5 Le modele statique preliminaire de notre etude de cas provient de la reunion 
~0 de tous les diagrammes precedents. 
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Accord Disaccord 



Comment proceder pour decouper ce modele en unites d'organisation 
metier ? 

• II est clair que toute la partie droite du modele (y compris l'entite session) 
concerne le catalogue de formation et constitue une unite coherente, rela- 
tivement stable dans le temps. 

• Le couple facture-comptable est aussi relativement independant du reste, et 
correspond d'ailleurs a un service bien identifie de l'entreprise. 

• Tout le reste est de la responsabilite du responsable formation et constitue 
un ensemble coherent, centre sur la demande de formation. 
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Nous pouvons representer cette structuration en decoupant le schema prece- 
dent grace a des packages stereotypes, comme cela a ete indique a l'etape 1 . 



Figure 7-22. 

Packages stereotypes 
representant la 
decoupe du modele 
metier 



Package stereotype, 
representant une unite 
d 1 organisation metier 




Com ptabi lite 

+ Comptable 
+ Facture 



Entites metier 
du package 





Demandes de formation Catalogue de formations 



+ Demande de formation 
+ Responsable formation 
+ Employe 
+ Inscription 
+ Reponse 
+ Accord 
+ Desaccord 



+ Catalogue 
+ Organisme de formation 
+ Formation 

+ Contenu 

+ Session 
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EXERCICE 7-14. 

Modele metier - diagramme de classes par package 



Dessinez un diagramme de classes par unite d'organisation, en essayant de minimiser 
les dependances entre packages. Ajoutez quelques attributs metier pertinents pour 
completer le modele metier statique. 

Elaborez un diagramme de classes complet par package. 
Commencez par un diagramme de packages avec des dependances. 



II est clair que le package Catalogue de formation peut etre autonome et 
O qu'il peut done constituer un composant metier reutilisable. II est egalement 
vT 1 logique de faire dependre la facture de la demande de formation plutot que le 
contraire. Le schema de dependances entre unites d'organisation metier que 
Ton obtient est done celui qui est presente ci-apres. II s'agit d'un diagramme 
de packages qui respecte les sacro-saints principes des dependances entre 
packages : 

• pas de dependances mutuelles ; 

• pas de dependances circulaires. 



Figure 7-23. 

Diagramme de packages 
montrant les dependances 
souhaitees entre packages 




i Demandes de formation 




Catalogue de formations 
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Cet objectif de dependances entre packages impose une contrainte sur la 
navigabilite des associations qui traversent deux unites d'organisation, de la 
facon suivante. 

emet 




Figure 7-24. 

Ajout des navigabilites sur les associations 
qui traversent deux packages 



Nous pouvons maintenant dessiner un diagramme de classes par package en 
ajoutant quelques attributs metier pertinents. Notez la presence sur les dia- 
grammes des classes reliees appartenant aux autres packages (avec 1' indica- 
tion « (from xxx) 4 »). 



4. Cette convention graphique efficace n'est pas standard UML. Elle a ete popularisee par l'outil Rational/Rose et reprise 
par Enterprise Architect. 
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Figure 7-26. 

Diagramme de classes 
du package Demandes 
de formation 




Accord 
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Figure 7-27. 

Diagramme de classes du package 
Catalogue de formations 



Organisme 
de formation 




Session 

dateDebut 
/ dateFin 
lieu 



audience 
prerequis 
objectifs 
outils 
plan 



On notera l'attribut derive /dateFin de Session. La contrainte pourrait s'ecrire 
simplement en OCL 5 : {self .dateFin = self .dateDebut + formation .duree }. 



Etape 4 - Analyse du domaine (partie dynamique) 



Exercice 7-15. 

Modele metier - diagramme d'etats 



Realisez le diagramme d'etats de la demande de formation. 



^ Quelles informations avons-nous deja reunies sur la dynamique d'une 
"o demande de formation ? 

Reprenons les trois premieres phrases de l'enonce : 

1 . Le processus de formation est initialise lorsque le responsable formation 
recoit une demande de formation de la part d'un employe. Cette demande 



5. 



OCL (Object Constraint Language) est un petit langage a expressions, permettant d'exprimer des contraintes sur les dia- 
grammes de classes UML au moyen d'expressions booleennes qui doivent etre verifiees par le modele. OCL fait partie 
integrante d'UML depuis la version UML 1.1. 
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est instruite par le responsable qui qualifie la demande et transmet son 
accord ou son disaccord a l'interesse. 

2. En cas d' accord, le responsable recherche dans le catalogue des forma- 
tions agreees un stage correspondant a la demande. II informe 1' employe 
du contenu de la formation et lui propose une liste des prochaines ses- 
sions. Lorsque 1' employe retourne son choix, le responsable formation 
inscrit le participant a la session aupres de l'organisme de formation con- 
cerne. 

3. En cas d'empechement, l'employe doit informer le responsable de forma- 
tion au plus tot pour annuler l'inscription ou la demande. 

Nous avions egalement realise un diagramme d'activite du processus de for- 
mation montrant les objets metier et leurs changements d'etats. 



: Employe 




Figure 7-28. 

Diagramme d'activite du processus de formation 



A partir de ce diagramme d'activite, nous pouvons tout d'abord identifier 
quatre etats principaux de la demande de formation, comme le montre la 
figure suivante. 
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Figure 7-29. 

Diagramme d'etats initial de la demande 
de formation 



1 



Attentelnstruction 



accord 



V 



Attentelnscription 



inscription 



V 



Satisfaite 



refus 



finSession 



Realisee 



En fait, en relisant attentivement la premiere phrase, nous nous apercevons 
que la demande est initiee par 1' employe et envoyee au responsable forma- 
tion, puis instruite par ce dernier qui transmet son accord ou son disaccord a 
l'interesse. Pour pouvoir completer le diagramme d'etats, nous allons reflechir 
a la suite de la vie d'une demande. Ceci nous amene a ajouter un etat avant 
Attente Instruction, puisque c'est la validation de la demande qui declenche la 
transmission au responsable formation. La creation proprement dite de cette 
demande n'est pas atomique, car l'employe doit effectuer plusieurs selections 
(theme, periode, etc.) avant de proceder a la validation. Nous avons egale- 
ment identifie des actions d' envoi de message qui se materialiseront par le 
mot-cle « send » sur les transitions du diagramme d'etats. 

Une nouvelle version plus complete du diagramme d'etats est representee sur 
la figure suivante. 
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Deuxieme version du diagramme d'etats 
de la demande de formation 



1 



Creation 



valider / 
send responsable.self 



Attente Instruction 



refuser / 
send employe. refus 



accepter / 
send employe. accord 



RechercheSession 



choixSession / 
send organisme.commande(self) 




refusee 



actions d'envoi 
de message 



Attente Inscription 



inscription / 
send employe. confirmation 



finSession 



Que peut-il bien nous manquer pour terminer notre diagramme d'etats ? En 
fait, toutes les transitions d'annulation ou d'erreur. L' employe peut ainsi 
annuler sa demande a tout moment, l'organisme de formation peut indiquer 
une annulation de session, etc. 

Le diagramme d'etats complet est represente sur la figure ci-apres. 
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Figure 7-31. 

Diagramme d'etats complex 
de la demande de formation 



i 



valider/ 
send responsable.self 



Attentelnstruction 



accepter / 
send employe. accord 



RechercheSession 



choixSession / 
send organisme.commande 



annulerSession / 
send employe. annulation 



Attentelnscription 



refuser / 
send employe. refus 




annuler / 
send organisme.annulation 



inscription / 
send employe.confirmation 



annuler/ 
send organisme.annulation 



m 



linSession 
terminee 



Etape 5 - Definition des iterations 



Nous allons maintenant definir des iterations a partir du travail deja effectue et nous fixer 
comme objectif la conception de la premiere de ces iterations avec le langage Java 
comme cible principale. 



EXERCICE 7-16. 

Planification des iterations 



Proposez une decoupe du projet en iterations a partir du travail d'analyse precedent (cas 
d'utilisation et modele metier statique). Ayez en particulier a l'esprit un des principes 
majeurs du processus unifie : guide par les cas d'utilisation. . . 



Decoupez le projet en iterations. 
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^ Au vu des dependances entre les packages metier, ainsi qu'entre les cas d'uti- 
lisation, il parait naturel de commencer par la gestion du catalogue. En effet, 

^\ les deux autres packages metier dependent de Catalogue de formations et le 
cas d'utilisation fondamental Demander une formation est relie par extension 
au cas Consulter le catalogue. Nous choisissons done de realiser les deux cas 
d'utilisation qui concernent le catalogue dans la premiere iteration. 

Pour la deuxieme iteration, il est indispensable de s'occuper du cas d'utilisa- 
tion principal du systeme, a savoir Demander une formation . 

Dans une troisieme iteration, nous traiterons les aspects plus administratifs 
(inscription, etc.) avec Traiter les demandes. 

Enfin, la derniere iteration ser consacree a Gerer ses demandes, un peu moins 
important fonctionnellement. 




II est a noter que le service plus technique d'authentification de l'employe ou 
du responsable formation sur l'intranet peut etre realise parallelement aux cas 
d'utilisation fonctionnels. 
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Etape 6 - Definition de I'architecture systeme 



Les systemes informatiques modernes sont organises en couches horizontales, elles- 
memes decoupees en partitions verticales. Cette decoupe est d'abord logique, puis even- 
tuellement physique en termes de machines. 

Le probleme general de I'architecture des systemes informatiques n'est pas le sujet de ce 
livre. Neanmoins, nous profiterons de cette quatrieme partie pour faire passer quelques 
idees fondamentales sur les architectures en couches dites « n-tiers », ainsi que sur les 
diagrammes UML qui sont utiles pour cette activite. 



A retenir ARCHITECTURE EN TROIS NIVEAUX 

L'architecture a trois niveaux, devenue maintenant classique, etait bien, 
au depart, une division logique, mais elle fut interpret.ee a tort comme 
pouvant impliquer des noeuds d'execution physiquement separes. 

Le principal objectif de cette separation en trois couches (3-tiers) est 
d'isoler la logique metier des classes de presentation (IHM), ainsi que 
d'interdire un acces direct aux donnees stockees par ces classes de 
presentation. Le souci premier est de repondre au critere d'evolutivite : 
pouvoir modifier I'interface de I'application sans devoir modifier les 
regies metier, et pouvoir changer de mecanisme de stockage sans avoir 
a retoucher I'interface, ni les regies metier. 



En voici 1' illustration, basee sur l'etude de cas du chapitre 2 : la caisse enregistreuse de 
supermarche. 



Architecture en trois couches 
de la caisse enregistreuse 

Presentation 



Caissocnregistreuse 


- m 


Numero 

Total 

Paiement 


Quantite 1 
a Rendre 


Saisie article 


Fin devente 


Saisie paiement 





Logique Traiter le passage 

encaisse 



Stockage 
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On ne considere plus aujourd'hui que cette decomposition en trois couches 
est suffisante si Ton a des objectifs importants de modularite et de reutilisa- 
tion. En effet, elle conduit les objets graphiques de presentation a connaitre le 
detail de la couche logique, ce qui nuit a leur maintenabilite et a leur reutilisa- 
bilite. 

Pour ameliorer cet etat de fait, l'idee consiste a introduire un objet artificiel, 
souvent appele « controleur » 6 , entre les objets graphiques et les objets 
metier. C'est l'objet de conception contrdleur qui connait maintenant l'inter- 
face des objets de la couche metier et qui joue le role de « facade » vis-a-vis 
de la couche presentation, comme cela est illustre sur la figure suivante. 



Tous ces nouveaux objets controleurs, introduits en conception, vont etre ras- 
sembles dans une nouvelle couche appelee « logique applicative », qui con- 
court a realiser les cas d'utilisation du systeme, et a isoler la couche 
presentation des objets metier, souvent persistants et tres reutilisables. 

L' architecture en trois couches peut ainsi etre completee avec deux couches 
supplementaires qui represented pour la premiere ces objets controleurs 



6. II s'agit du deuxieme GRASP Pattern propose par Larman dans [Larman 05] . Le nom de controleur fait egalement refe- 
rence au pattern bien connu MVC (Model - View - Controller), ainsi qu'aux classes « control » de Jacobson, dont nous 
parlons plus loin dans ce chapitre. 
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Figure 7-34. 

Diagramme illustrant I'ajout 
de l'objet contrdleur 




Stockage 
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decouplant la presentation du metier et pour la seconde des services techni- 
ques generaux tels que Faeces aux bases de donnees, la generation de rap- 
ports, etc. 

Nous allons utiliser ces principes d' architecture multicouches dans la suite du 
chapitre dans le cadre du systeme de gestion des demandes de formation. 



A retenir PACKAGES, COUCHES ET PARTITIONS 



En UML, le seul mecanisme de regroupement de classes disponible est le 
package. Par consequent, les couches horizontales et les partitions 
verticales se traduisent egalement par des packages. 

Ainsi, une architecture en couches se decrit par un diagramme statique 
qui ne montre que des packages et leurs dependances. UML 2 a reconnu 
I'importance de ce type de diagramme de haut niveau en officialisant le 
diagramme de packages comme un type de diagramme UML a part 
entiere. Vous pouvez utiliser le mot-cle « layer » pour distinguer les 
packages qui representent les couches. 



Figure 7-35. 

Representation UML d'une couche logicielle 





EXERCICE 7-17. 

Architecture en couches preliminaire 



Proposez un diagramme d' architecture preliminaire du projet sur la base des recomman- 
dations precedentes. 

Elaborez un diagramme de packages d'architecture. 



Nous decrivons done un package stereotype « layer » par couche logicielle. 
O A l'interieur de chaque couche, nous donnons une structure preliminaire en 
partitions. 
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Figure 7-36. 

Architecture 
en couches 
du systeme 
de gestion 
des demandes 
de formation 




classes de 
base utilisees 
par toutes les 
couches 



«layer» 
Services techniques 



Authentication 



La couche metier comprend a priori les trois packages identifies a l'etape 3 : 
Comptabilite 1 ' , Demandes et Catalogue. Cette decoupe pourra etre affinee par 
la suite dans notre etude ; il ne s'agit que d'une structuration preliminaire. 

La couche applicative n'est pas detaillee sur le schema. Elle peut etre structu- 
red soit a l'identique de la couche metier, soit au contraire d'un point de vue 
fonctionnel en calquant les packages de cas d' utilisation. 

La couche presentation regroupe plutot les classes graphiques des interfaces 
respectives du responsable et de l'employe. 



7. La partie relative a la comptabilite ne fait en toute rigueur pas partie du systeme informatique, comme indique lors de 
1' etude des cas d'utilisation. Nous la conservons neanmoins dans la suite de l'exercice pour travailler sur une architec- 
ture logique de taille consequente. 
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La couche des services techniques comprend au moins un package pour gerer 
le service technique d'authentification, identifie des l'etape 1. 

Enfin, il ne faut pas oublier les classes de base Java fournies par le JDK et qui sont 
utilisees par toutes les couches. La couche presentation par exemple va utiliser les 
classes graphiques. La couche des services techniques quant a elle va en particulier 
utiliser les classes JDBC d'acces aux bases de donnees relationnelles. Toutes les 
couches vont se servir des classes de base telles que les conteneurs, les dates, etc. 

II faut toutefois bien considerer que cette architecture preliminaire pourra etre 
affinee ou modifiee (principalement au niveau des partitions a l'interieur de 
chaque couche) par le travail de conception qui va suivre. N'oubliez pas que 
le processus d' analyse/ conception est fondamentalement iteratif. 



Etape 7 - Definition des operations systeme (iteration #1) 



Exercice 7-18. 
Operations systeme 

La premiere iteration correspond aux cas d'utilisation Consulter le catalogue et Mettre a 
jour le catalogue. Les concernant, on a precede a une description de haut niveau a 
l'etape 1 (exercice 7-3). Nous citons pour memoire : 

« Le responsable formation peut introduire une nouvelle formation dans le catalogue, 
modifier une formation existante ou supprimer une formation supprimee par un orga- 
nisme. II peut egalement modifier les regroupements de formations appeles themes. II a 
aussi la possibilite de mettre a jour les dates et lieux des sessions. 

Pour demander une formation et pour maintenir le catalogue, le systeme doit proposer 
une fonctionnalite de base de consultation du catalogue. 




Repertoriez les operations systeme pour le cas d'utilisation Mettre a jour le 

CATALOGUE. 



Les operations systeme pour le cas d'utilisation Mettre a jour le catalogue se 
O deduisent facilement de sa description de haut niveau. II faut neanmoins pen- 
vT* ser a la creation et a la maintenance des organismes de formation, ce qui 

n'apparait pas clairement dans le texte. 

Les operations systeme sont rassemblees sur le schema suivant, ou une classe 
symbolise le systeme vu comme une boite noire, avec ses operations. 
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Figure 7-37. 

Operations systeme pour le cas d 'utilisation Mettre a jour le catalogue 



Systeme 



creerFormationO 

modifierFormation() 

creerOrgaFormation() 

modifierOrgaFormation() 

creerTheme() 

modifierThemeO 

creerSession() 

modifierSession() 



Pour simplifier, nous avons considere que Taction de modification inclut tou- 
jours la suppression et nous avons omis les operations de consultation pure. 



EXERCICE 7-19. 

Contrat d'operation systeme 

Nous avons identifie les operations systeme a l'etape precedente. Mais comment 
pouvons-nous specifier le resultat de l'execution d'une operation systeme ? 

A retenir CONTRAT D'OPERATIONS 

Larman a propose dans [Larman 05] d'etablir un « contrat » pour chaque 
operation systeme. 

Un contrat d'operation decrit les changements d'etat du systeme quand 
une operation systeme est effectuee. Ces modifications sont exprimees 
en termes de « post-conditions » qui detaillent le nouvel etat du 
systeme apres l'execution de I'operation. 

Les principals post-conditions concernent la creation (ou la destruc- 
tion) d'objets et de liens issus du modele statique d'analyse, ainsi que la 
modification de valeurs d'attributs. Les contrats d'operations permettent 
ainsi de faire le lien entre le point de vue fonctionnel/dynamique des 
cas d'utilisation et le point de vue statique d'analyse. 

Un plan type de description textuelle de contrat d'operation est donne 
ci-apres : 

• nom 

• responsabilites 

• references 

• pre-conditions 

• post-conditions 

• exceptions (optionnel) 

• notes (optionnel) 
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Redigez le contrat de I'operation systeme creerFormation. 



En premier lieu, nous allons extraire du diagramme de classes du package 
O Catalogue deformations (voir figure 7-27) la partie concernee par notre ques- 
vT* tion. En effet, les operations systeme creerFormation et creerTheme vont agir 

sur des objets et des liens provenant du diagramme suivant : 



Figure 7-38. 

Diagramme de classes du package 
Catalogue de formations 



Organisme 
de formation 




Session 

dateDebut 
/ dateFin 
lieu 



audience 
prerequis 
objectifs 
outils 
plan 



Cependant, faisait defaut la notion de theme dans notre modele metier. Ce 
concept de theme est purement applicatif : il facilite le travail de 1' employe 
lors d'une demande de formation en lui permettant de rester volontairement 
imprecis et de ne pas choisir une formation particuliere, mais plutot un 
ensemble de formations sur un sujet donne. 

Nous supposerons que les themes structurent le catalogue, mais qu'ils ne le 
partitionnent pas : une formation appartient a au moins un theme. La figure 
suivante montre les modifications apportees par 1' introduction du concept de 
theme. 
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Figure 7-39. 

Introduction du concept de theme 



Q 



Q 



1..* 




Catalogue 



Theme 




1.." 



0..* 



Q 



Formation 



Nous pouvons maintenant decrire le contrat de l'operation creerFormation : 

• Nom 
creerFormation. 

• Responsabilites 

Creer une nouvelle formation d'apres la description fournie par l'organisme 
de formation concerne et la classer dans au moins un des themes existants. 

• References 

Cas d'utilisation Mettre a jour le catalogue. 

• Pre-conditions 

- le catalogue de formations existe ; 

- il y a au moins un theme dans le catalogue ; 

- l'organisme fournisseur de la formation existe deja dans le catalogue ; 

- le responsable est connecte sur l'intranet. 

• Post-conditions 

- une formation f a ete creee avec ses attributs ; 

- un objet contenu c a ete cree avec ses attributs ; 

- c a ete lie a f ; 

- f a ete liee a 1'organisme fournisseur ; 

- d'eventuels objets sessions ont ete crees avec leurs attributs ; 

- ces objets sessions ont ete lies avec f ; 

- f a ete liee a au moins un theme. 
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Etape 8 - Diagrammes d'interaction (iteration #1) 



Les contrats d'operations constituent le dernier livrable en matiere d'analyse. En effet, 
s'ils decrivent ce que fait une operation en termes de changements d'etat, ils ne doivent 
pas encore decrire comment elle y precede. 

C'est justement le travail du concepteur de choisir comment les objets logiciels vont 
interagir entre eux pour realiser telle ou telle operation. Jacobson 8 a propose le premier 
(encore lui !) des stereotypes de classes pour decrire la realisation d'un cas d'utilisation. 
Nous allons nous inspirer de ses travaux pour remplacer le systeme vu comme une boite 
noire (du point de vue de 1' analyse) par des objets logiciels (du point de vue de la 
conception), comme cela est illustre par les diagrammes de sequence presentes ci-apres. 



systeme vu 
comme une 
boite noire 



: Responsable 



creerFormation( ) 




Figure 7-40. 

Passage de I 'analyse a la conception 



objets 
logiciels a 
1' interieur 
du systeme 



: Responsable 




creerFormationf ) 



Conception 



A retenir STEREOTYPES DE JACOBSON 

A I'interieur du systeme, Jacobson distingue les trois stereotypes 
suivants : 

- «boundary» : classes qui servent a modeliser les interactions 
entre le systeme et ses acteurs ; 

- «control» : classes utilisees pour representer la coordination, 
I'enchainement et le controle d'autres objets - elles sont en general 
reliees a un cas d'utilisation particulier ; 

- «ent±ty» : classes qui servent a modeliser des informations 
durables et souvent persistantes 



8. Voir en particulier The Unified Software Development Process, I. Jacobson et al., 1999, Addison Wesley, p. 44. 
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Nous utiliserons ces trois stereotypes (avec leurs symboles graphiques associes, dans les 
diagrammes de sequence) pour montrer graphiquement comment un message emis par 
un acteur traverse les couches presentation, application et metier 9 . 



Figure 7-41. 

Illustration des 
trois stereotypes 
de Jacobson sur 
un diagramme de 
sequence 





: <Actor Name> 



: <Bounda ry Name> 



: <Control Name> 



: <Entity Name> 



<Entity Name> 



messages . 
synchrones 



— re tours. 



J 



ligne de 



t focus of 
control 



Notez la representation des « focus of control » - bandes blanches qui repre- 
sented les periodes d'activite sur les lignes de vie des objets -, ainsi que les 
Heches en pointille de retour d' invocation d'une operation. 



messages avec 
numerotat 
decimal! 



Entity Name> 



Figure 7-42. . . ., 

° : <Actor Name: 

Illustration des trois stereotypes 
de Jacobson sur un diagramme 
de communication 




<Entity Name> 



Notez la numerotation decimale qui permet de montrer l'imbrication des 
messages, d'une facon comparable a la representation des « focus of control » 
sur le diagramme de sequence precedent. 



9. Meme si Jacobson (et le RUP de Rational) presente ses stereotypes comme des types de classes d'analyse, nos preferons 
parler pour notre part de conception preliminaire. Nous detaillerons ensuite cette conception logique en fonction de la 
plate-forme de developpement choisie (J2EE, .NET, etc.) et remplacerons par exemple les « boundary » par des JSP 
(J2EE) ou des ASP (.Net), etc. 




Conception 



QUATRIEME P ARTIE 




EXERCICE 7-20. 

Diagrammes d'interaction de conception 



Realisez un diagramme de sequence ou un diagramme de communication qui montre la 
realisation de 1' operation systeme creer Formation. 

Realisez un diagramme d'interaction pour CREERFORMATION. 

O Que devons-nous faire ? Pour le savoir, il nous faut reprendre toutes les post- 
~0 conditions repertoriees lors de l'etape precedente : 

• une formation f a ete creee avec ses attributs ; 

• un objet contenu c a ete cree avec ses attributs ; 

• c a ete lie a f ; 

• f a ete liee a l'organisme fournisseur ; 

• d'eventuels objets sessions ont ete crees avec leurs attributs ; 

• ces objets sessions ont ete lies avec f ; 

• f a ete liee a au moins un theme. 

N'oubliez pas que les post-conditions ne representent que le nouvel etat du 
systeme a la fin de 1' execution de 1' operation systeme. Elles ne sont absolu- 
ment pas ordonnees : c'est le role du concepteur de choisir maintenant quel 
objet doit realiser chaque action, et dans quel ordre. 

La post-condition fondamentale concerne bien la creation de 1' objet forma- 
tion, avec son contenu et ses sessions, puis la definition de ses liens avec les 
autres objets du catalogue tels que les themes et les organismes. II est raison- 
nable de penser que la creation de l'objet formation f va se faire en quatre 
etapes : 

1 . initialisation de l'objet f et de ses attributs ; 

2. creation de son contenu ; 

3 . creation des sessions ; 

4. validation de f. 



Voyons par le detail une solution possible pour la premiere etape, mettant en 
jeu deux objets «boundary», un «control» et un «ent±ty». 
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: Responsable 
Formation 




: EcranGeneral : EcranFormation 



: ControleurFormations 



_!_. creerFormation( ) 



active r( ) 



V 



initialiser (titre, duree, prix) 



initialiserFormation(titre, duree, prix) 

to 



representation 

d'un objet 

nouvellement 



f : Formation 
create{titre, duree, prix) 



z — y 



Figure 7-43. 

Diagramme de sequence de V initialisation de f 



' message de 
creation 



Le meme scenario peut se representer par un diagramme de communication, 
comme ceci : 




: EcranFormation . ControleurFormations 



Figure 7-44. 

Diagramme de communication 
de 1' initialisation de f 



Conception 

QUATRIEME P ARTIE 



Poursuivons par la creation du contenu. Le diagramme de sequence complete 
devient alors : 



: Responsable 
Formation 



' creerFormation( ) 



KD K3 KD O 

: EcranGeneral ; EcranFormation : EcranContenu : Con 



ControleurFormations 



initialiserFormation( titra, duree, prix) 



creerContenufaudience, prereq; 



creerContenjj( ) 



initialiserFormation(titre, duree, prix) 



;,objectifs,outils, plan) j 



Q 



create(titre, duree, prix) 

— 



V 



Q 



creerContenu(audience, | 
orerequis, objectifs.outils. pl*i) C reate(audienck prerequis, 

^■'i obiectifs.outils, plan) ,£ : Contenu 

1 *Tl 



Figure 7-45. 

Diagramme de sequence de V initialisation defet de la creation de son contenu 



On notera que le diagramme de sequence devient de moins en moins lisible au 
fur et a mesure que nous ajoutons des objets... C'est pour cette raison simple 
que le diagramme de communication est interessant en conception : il nous 
permet de disposer nos objets dans les deux dimensions afin d'ameliorer la lisi- 
bilite du schema. 

Le diagramme de communication qui correspond au diagramme de sequence 
precedent est donne sur la figure suivante, a titre de comparaison. 
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! . creerFormationi ) 



Presentation 



i 



\ 2. initialiser (litre, duree, prix) 

3. creerContenuf ) 



Metier 



I V 

Application 



For nation \ 



o 



i 



2.1. initial,serFormation(titre. duree, prix) 

r 



; q 



1 f : Formation 



4. creerContenu(audience, prerequis : 
□bjectifs, outils. plan) 



2.1M. create( titre, duree, prix) 



: ControleurFormatioi 



4.1. ere erConte^iu( audience, 
prerequis, objedjfs, outils. plan) 



Figure 7-46. 

Diagramme de communication de V initialisation 
defet de la creation de son contenu 



: EcranContenu ' 



4.1.1.1 

prerequfe, objectifs, outils, plan) 



On notera que le diagramme de communication presente ci-dessus permet de 
bien differencier visuellement les couches d'objets. 

Poursuivons maintenant par la creation des sessions. 



A retenir MULTI-OBJET 

Pour indiquer que la formation f sera liee a une collection de sessions, 
nous utilisons un multi-objet Le multi-objet est une construction 
UML 1 qui represente en un seul symbole plusieurs objets de la meme 
classe b . Cela permet de ne pas ajouter trap tot de classes de conception 
detaillee liees au langage de programmation (comme Vector de la STL 
C++ ou ArrayList en Java, etc.). Un multi-objet peut egalement repre- 
senter I'abstraction entiere d'une connexion a une base de donnees. 

Nous avions d'ailleurs oublie dans le diagramme 7-45 de creer la 
collection vide de sessions lors de la creation de f. II suffit ensuite apres 
la creation de chaque session de I'ajouter a la collection. Nous utilisons 
pour cela une operation generique addQ : voir figure 7-47. 

b. Cette notation tres repandue se trouve avoir disparu dans la version 2.0 du langage UML. Nous continuons 
cependant a l'utiliser dans le reste du chapitre pour des raisons de lisibilite et de clarte pedagogique. Le lecteur 
curieux se referera au chapitre suivant pour voir par quoi cette notation UML 1 a ete remplacee en UML 2. 
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Le diagramme de communication presente un autre avantage sur le dia- 
gramme de sequence : il permet de representer les relations structurelles entre 
les objets. Nous avons par exemple fait figurer les liens de composition autour 
de l'objet formation f , pour mieux preparer la tracabilite avec notre futur dia- 
gramme de classes de conception. 



1 . creerFormation( ) 



2. initialiser (titre, duree, prix) 
3. creerContenuf ) 
5. creerSesssion( ) 



6.1 .1 . create( dateDebut, lieu 



: Responsable 
Formation 



4. creerContenu(audience, prerequis, 
objectifs, outils, plan) 



16. creerSession(dateDebLit, lieu) 




2.1. initialiserFormation( titre, 
duree, prix) 



3.1. activerf ) 



4.1. creerContenu(audience, 
prerequis, objectifs, outils, plan) 




6.1. creerSession( dateDebut, lieu) 



4.1 .1 . create(audience, 
prerequis, objectifs, outils, plan) 



Q 



: EcranSessions 

Figure 7-47. 

Diagramme de communication de V initialisation def, 
de la creation de son contenu et d'une session 



II ne nous reste plus qu'a lier la formation f a un theme existant et a valider la 
creation. En comparant le travail realise aux post-conditions qui etaient souhai- 
tees au debut de la reponse, on peut constater que la suivante n'a pas ete prise 
en compte : « f a ete liee a l'organisme fournisseur ». Nous l'ajoutons simple- 
ment aux responsabilites du controleur, lors de la creation de la formation. 

Le diagramme de communication complet de l'operation systeme 
creerFormation se trouve sur la figure suivante. Remarquez la quantite 
d' information, assez considerable, qui arrive a etre representee de facon 
encore a peu pres lisible sur une seule page. Neanmoins, nous atteignons la 
les limites du diagramme de communication. 
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1 . creerFormationj ) 



2. initialiser (titre, duree, prix) 
3. creerContenu( 
5. creerSesssionf 
7. valider(theme] 



X 



:Responsable 5.1 . activer( ) 

Formation 



4. creerContenu(audience, prerequis, 
objectifs, outils, plan) 




2.1.1.create( titre, 
duree, prix) 

: ControleurFormations 71 1 ■ valider ( 



K3 



4.1. creerContenufaudienc ; 
prerequi s, objec tifs, outils, pi 



J 



creerSession(dateDebut, lieu) 



: EcranContenu 

6.1. creerSessionfdate Debut, lieu) 



f : Formation 



4.1 .1 . createfaudience, 
prerequis, objectifs, outils, plai 



7.1.2. add(f) 



Q 



■Q 



6 



: EcranSessions 

Figure 7-48. 

Diagramme de communication complex de {'operation systeme 
creerFormation 



Une idee interessante pour ameliorer la lisibilite du diagramme consiste a le 
decouper en deux en prenant l'objet controleur comme charniere : 

• une premiere partie afin de specifier la cinematique de l'interface homme- 
machine avec les acteurs, les objets «boundary» et l'objet 
«control» ; 

• une seconde partie afin de specifier la dynamique des couches applicatives 
et metier avec l'objet «control» et les objets «entity». 

Les diagrammes de communication partiels ainsi obtenus sont montres sur les 
deux figures qui suivent. 
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1 . creerFormation( ) 



2. initialiser (titre, duree, prix) 
3. creerContenu( ) 
5. creerSesssion( ) 
7. valider(theme) 



1.1.activer( ) 



2.1 . initialiserFormation(litre, duree, prix) 
7.1 . valider(theme) 



: Ecran Formation 



: Responsable 
Formation 



5.1 . activer( 



Figure 7-49. 

Diagramme de 
communication partiel 
de V operation systeme 
creerFormation : 
couche presentation 
et lien avec la couche 
applicative 



4. creerContenu(audienceprerequis 
objectifs,outils, plan) 



6. creerSessionp'ateDebLit, lieu) 




r-6 



4.1 . creerContenu(audience, 
prerequis,objectits,outils, plan) 



: ControleurFormations 



6.1 .creerSession^teDebut, lieu) 



: EcranSessions 



3.1. create( dateDebut, lieu) 



1. initialiserFormation( titre, duree, prix) 

2. creerContenufaudience, prerequis, 

objectifs, outils, plan) 

3. creerSessionf dateDebut, lieu) 

4. valider(theme) 



1.1.1. create 



Figure 7-50. 

Diagramme de communication partiel de 
I 'operation systeme creerFormation : couche 
applicative et lien avec la couche metier 




: ControleurFormations 
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Etape 9 - Diagrammes de classes de conception 
(iteration #1) 



Chaque operation systeme va donner lieu a une etude dynamique sous la forme d'un 
diagramme d'interaction, comme cela a ete le cas pour l'operation creerFormation lors 
de l'exercice precedent. 




Demarche de conception initialisee 
par les operations systeme 



Les diagrammes d'interaction ainsi realises vont permettre d'elaborer des 
diagrammes de classes de conception, et ce en ajoutant principalement les 
informations suivantes aux classes issues du modele d'analyse : 

• les operations : un message ne peut etre recu par un objet que si sa classe a 
declare l'operation publique correspondante ; 



Figure 7-52. 


message 






Rapport entre message et operation 




1:op1() 






A 




: B 












• la navigabilite des associations ou les dependances entre classes, suivant 
que les liens entre objets sont durables ou temporaires, et en fonction du 
sens de circulation des messages. 
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A retenir LIENS DURABLES OU TEMPORAIRES 



Un lien durable entre objets va donner lieu a une association navigable 
entre les classes correspondantes ; un lien temporaire (par parametre : 
« parameter », ou variable locale : « local ») va donner lieu a une 
relation de dependance. 

Sur I'exemple presente ci-apres, le lien entre I'objet :Aet I'objet :B devient 
une association navigable entre les classes correspondantes. Le fait que 
I'objet :A recoive en parametre d'un message une reference sur un objet 
de la classe C induit une dependance entre les classes concernees. 



reference comme 
_y parametre 



Figure 7-53. 

Rapport entre les liens 
entre objets et les 
relations entre classes 



op (c : C) 




1:op1() 






: A 




:B 

















dependance 




Notez enfin que nous recommandons de ne pas ajouter les classes qui correspondent aux 
multi-objets dans le diagramme de classes de conception de fafon a rester le plus long- 
temps possible independant du langage de programmation cible. 




EXERCICE 7-21. 

Diagramme de classes de conception 



En appliquant les regies enoncees plus haut, Realisez un fragment de diagramme de 
classes de conception a partir du diagramme de communication partiel 7-50 (creer- 
Formation). 

Commencez un diagramme de classes de conception pour CREERFORMATION. 
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von 

J~ Le diagramme de communication 7-50 nous permet tout d'abord d'ajouter les 
O operations dans les classes comme cela est montre sur le schema suivant. 



«entity» 
Session 




«control» 
ControleurFormations 
(from Logique applicative) 



nitialiserFormation( titre, duree, prix) 
creerContenu(audience, prerequis, objectifs, outils, plan) 
creerSession( dateDebut, lieu) 
valider(theme) 




Figure 7-54. 

Operations dans les classes de conception 



«entity» 
Contenu 




«entity» 
Organisme 



«entity» 
Theme 



On notera qu'il y a peu d'operations puisque nous ne faisons pas apparaitre : 

• Les operations de creation (message create), 

• Les operations generiques sur les classes conteneurs (addQ, etc.). 

Neanmoins, on peut remarquer un premier probleme : comment l'objet Con- 
troleurFormations peut-il ajouter la nouvelle formation f au multi-objets de 
l'organisme correspondant sans posseder une reference sur cet organisme ? 



Figure 7-55. 

Diagramme de communication restreint au premier 
message de I 'operation systeme creerFormation 




„ . . ._ duree, prix) 

: ControleurFormations f ; Formation 



I.I.I. UCQLC 
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Cela signifie que nous devons ajouter un parametre a l'operation 
initialiser Formation : une reference vers un organisme existant. 

Si nous utilisons egalement les mots-cles « parameter » et « local » 
pour indiquer les liens temporaires entre objets, le diagramme de communi- 
cation precedent est modifie comme suit : 



Figure 7-56. 

Diagramme de communication 
complete 



1. initialiserFormation( titre, duree, 
prix, organisme) 




ControleurFormations 



Nous allons maintenant completer le diagramme de classes en ajoutant les rela- 
tions entre classes : association (avec ses variantes : agregation ou composition) 
et dependance. Le travail est facilite en ceci que nous avions deja indique les 
liens de composition et d'agregation sur le diagramme de communication. 



Figure 7-57. 

Diagramme de classes 
complete d'apres 
le diagramme 
de communication 
precedent 



dependance 



«entity» 
Organisme 



«parameter» , 



«control» 
ControleurFormations 
(from Logique applicative) 



initialiserFormation(titre, duree, prix, organisme) 



0..1 



«entity» 
Formation 



«entity» 
Session 




{ordered} 



On notera l'utilisation du mot-cle « parameter » sur la dependance entre 
les classes ControleurFormations et Organisme, pour refleter le type de lien 
temporaire qui existe entre les objets correspondants dans le diagramme de 
communication. 
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Si nous appliquons maintenant la meme demarche sur l'ensemble du dia- 
gramme 7-50, nous obtenons le diagramme de classes de conception ci-apres. 
II faut noter que nous avons fait figurer les attributs dans les classes, mais pas 
les parametres des operations (pour simplifier le schema). 



Figure 7-58. 

Diagramme de classes de conception 
complete 



«parameter» 



«local» 
> 



«entity» 
Session 



dateDebut 
lieu 



«entity» 
Organisme 



- nom 

- adresse 

- numTel 

- numFax 

- email 



«control» 
ControleurFormations 
(from Logique applicative) 



initialiserFormation() 
creerContenu() 

■ creerSessionf) 

■ validerQ 



->| 

«local» 



«entity» 
Contenu 



audience 

prerequis 

objectifs 

outils 

plan 




- validerQ 



-> 



«parameter» 



«entity>: 
Theme 



Bien sur, ce diagramme est encore dans un etat tout a fait provisoire : 

• les choix de navigabilite des associations sont loin d'etre definitifs - ils 
pourront etre modifies par 1' etude des autres operations systeme ; 

• les dependances se transformeront peut-etre en associations si les objets 
requierent un lien durable, et non un simple lien temporaire, dans le cadre 
d'autres operations systeme. 
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EXERCICE 7-22. 

Amelioration de la conception 

A partir des diagrammes realises lors de la question precedente, proposez des ameliora- 
tions a la conception objet qu'ils illustrent. 

Ameliorez les diagrammes de conception precedents. 



O Le diagramme de classes 7-58 presente une classe ControleurFormations 
~0 couplee a toutes les autres classes ! Cette propriete est tout a fait contraire a 

un principe fondamental de la conception objet, appele couramment 

« couplage faible ». 



Le « couplage » represents une mesure de la quantite d'autres classes 
auxquelles une classe donnee est connectee , dont elle a connaissance, 
ou dont elle depend. 




1 - ( 

a- 



Conserver un couplage faible est un principe qu'il faut bien avoir a 
I'esprit pour toutes les decisions de conception ; c'est un objectif sous- 
jacent a evaluer d'une facon continue. En effet, en y pourvoyant, on 
obtient en general une application plus evolutive et plus facile a main- 
ten ir. 

La notion d'objet « controleur » que nous avons detaillee precedemment 
(voir figure 7-34) est un bon exemple de moyen mis en oeuvre pour 
minimiser le couplage entre les couches logicielles. 
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Essayons de voir s'il n'existe pas un moyen simple de reduire le couplage de la 
classe ControleurFormations sans augmenter pour autant celui des autres classes. 

Reprenons le diagramme de communication 7-50. L'objet ControleurForma- 
tions est-il vraiment le mieux place pour creer les objets Contenu et Session ? 
Ne pourrait-il pas plutot deleguer cette responsabilite de creation a l'objet 
Formation qui va de toute facon etre ensuite lie d'une facon durable a son 
contenu et a ses sessions ? De cette maniere, nous enlevons les deux depen- 
dances entre ControleurFormations et Contenu et Session, sans en ajouter, 
puisque Formation est deja couplee a Contenu et Session par des relations 
fortes de composition. 

Le diagramme de communication peut done etre modifie comme le montre la 
figure suivante. 



Figure 7-60. 

Diagramme de communication ameliore 
de V operation systeme creerFormation 



Q 




1.irtitialiserFormation(titre,duree, prix, organisme) 
4. validerftheme) 



2. creerContenutaudience, prerequis, 
objectifs,outils, plan) 



K) 



3. creerSession( dateDebut, lieu) 



: EcranSessions 




Le diagramme de classes de conception est ainsi allege de deux dependances, 
simplement parce que l'objet ControleurFormations a su deleguer une partie 
de ses responsabilites a l'objet Formation. En fait, cet exemple simple est tout 
a fait representatif du travail iteratif devaluation et d' amelioration que doit 
faire tout concepteur en matiere de conception objet. 
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Pour terminer, nous allons completer le diagramme de classes ameliore par 
les types des attributs, et proceder a la signature complete des operations 
(parametres avec leur type). II faut bien noter que nous utilisons des types 
simples du langage Java (comme int et short), des classes de base Java 
(comme String et Date), des classes « primitives » utilisateur (comme 
Numero et Email), qu'il faudra definir precisement, et enfin des classes du 
modele (comme Theme et Organisme). 



Figure 7-61. 

Diagramme de classes 
de conception ameliore 



«control» 
ControleurFormations 
(from Logique applicative) 



- initialiserFormation(titre : String, duree : short, prix : int, organisme : Organisme) 

- creerContenu(audience : String, prerequis : String, objectifs : String, outils : String, plan : String) 

- creerSession(dateDebut : Date, lieu : String) 

- valider(theme : Theme) 



\|/ «parame ter» 



«entity» 
Organisme 



nom : String 
adresse : String 
numTel : Numero 
numFax : Numero 
email : Email 



«parameter» 



«entity» 
Theme 



nom : String 





«entity» 




Formation 


- titre : String 




- duree : short 




- prix : int 




+ creerContenufaudience 


String, prerequis : String, objectifs : String, outils : String, plan : String) 


+ creerSession(dateDebut 


: Date, lieu : String) 


+ valider(theme : Theme) 





«entity» 
Contenu 



audience : String 
prerequis : String 
objectifs : String 
outils : String 
plan : String 



«entity» 
Session 



- dateDebut : Date 

- lieu : Adresse 
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Etape 10 - Definition des operations systeme (iterations #2 et #3) 



A ce stade, nous tenons pour acquis que l'iteration 1 a ete realisee avec succes. Les cas 
d'utilisation Consulter le catalogue et Mettre a jour ont ete concus, implemented et 
testes. Le package metier Catalogue de formations a ete afnne et enrichi en conse- 
quence. Un etat possible de son diagramme de classes de conception (ne montrant que 
les classes «ent±ty») est presente sur la figure suivante. 



«entily» 
Catalogue 


1 

+> 


i »■■* 


- periode : TimePeriod 




+ getFormationsByTheme(theme : Theme) 

+ getForma1ionByTitre(titre : String) 

+ getThemeByNom(nom : String) 

+ getSessionsByDate(dateDebut : Date) 

+ getAIIEIements() 

+ ... 




\ 




«entity» 
ElementCatalogue 







Figure 7-62. 

Diagramme de classes 
de conception du package 
Catalogue 



«parameter» 



«entity» 
Theme 



■ nom : String 



«entity» 
Session 



dateDebut : Date 
lieu : Adresse 



3 



{ordered} 



«entity» 
Formation 



■ titre : String 

■ duree : short 

■ prix : int 



+ creerContenu(audience : String, prerequis : String, objectifs : String, outils : String, plan : String) 
+ creerSession(dateDebut : Date, lieu : String) 
+ valider(theme : Theme) 

+ modifierContenu(audience : String, prerequis : String, objectifs : String, outils : String, plan : String) 
+ modifierSession(dateDebut : Date, lieu : String) 
+ modifierTheme(theme : Theme) 
+ annulerSession() 



1..' 



«entity» 
Organisme 



nom : String 
adresse : String 
numTel : Numero 
numFax : Numero 
email : Email 



I 



«entity» 
Contenu 



audience : String 
prerequis : String 
objectifs : String 
outils : String 
plan : String 



On notera que de nombreuses operations ont ete ajoutees, ainsi qu'une classe abstraite 
ElementCatalogue qui englobe les themes, les formations et les sessions, dans l'optique 
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de la creation d'une demande de formation par un employe a partir d'un element quel- 
conque du catalogue de formations. 

Le stockage du catalogue dans une base de donnees relationnelle est operationnel, ainsi 
que l'interface homme-machine des deux cas d'utilisation. 

Le mecanisme d'authentification est egalement disponible dans une version qui va nous 
permettre de continuer notre travail. 



EXERCICE 7-23. 

Operations systeme 

Nous allons maintenant concevoir et implementer les deuxieme et troisieme iterations 10 . 
Commencons done par le cas d'utilisation Demander une formation. Sa description de 
haut niveau a ete realisee a l'etape 1 (exercice 7-3). Nous la citons pour memoire : 

« L' employe peut consulter le catalogue, et selectionner un theme, ou une formation, ou 
meme une session particuliere. La demande est automatiquement enregistree par le 
systeme et transmise au responsable formation par e-mail. » 

Pour le second cas, Traiter les demandes, la description etait la suivante : 

« Le responsable formation va utiliser le systeme pour indiquer aux employes sa 
decision (accord ou refus). En cas d'accord sur une session precise, le systeme va 
envoy er automatiquement par fax une demande d' inscription sous forme de bon de 
commande a l'organisme concerne. » 

Listez les operations systeme pour les cas d'utilisation Demander une formation 

et TRAITER LES DEMANDES. 

• x on 

— Nous allons tout d'abord realiser un diagramme de sequence systeme du sce- 
^ nario nominal du cas d'utilisation Demander une formation. 

Nous supposons que l'employe peut effectuer plusieurs demandes, d'ou le 
cadre loop. Les selections d'une formation et d'une session sont optionnel- 
les, d'ou les deux cadres opt imbriques. Notez egalement la possibilite 
qu'offre UML 2 de representer graphiquement les preconditions en haut de la 
ligne de vie du systeme boite noire. 



10. Nous groupons les iterations par deux uniquement a des fins pedagogiques, afin que les differents modeles realises 
soient le plus interessant possible. 
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Figure 7-63. 

Diagramme 
de sequence 
systeme de 
Demander une 
formation 



sd DSS Demander une formation 



:Employe 



loop 



opt 



opt 



« system » 

:SGDF 



C {employe A 
authentifie} J 



consulterCatalogue() 



<3 j_j 



choisirTheme{) 



formations du theme 



choisi rFormation() 



sessions disponibles 



choisi rSession() 



infos session 



SI 



:Resp. formation 




nouvelle demande 



TJ 



Nous allons ensuite realiser un diagramme de sequence systeme simplifie 
(sans traiter le cas d'acceptation de demande incomplete) du cas d'utilisation 
Tr aiter les demande s. 
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sd Traiter les demandes 



:Resp. formation 



«system» 
:SG DF 



:Employe :Organisme de formation 



/{Responsable 
I identifie} 



consul terDem andes() 



< 



demandesactives 



loop 



choisi rDemandeQ 



detail demande 



3 



alt / \ 

[acceptation] 



acce p terDem a nde{) 



[refus] 



refuserDemande() 



refus(motif) 



V 



Figure 7-64. 

Diagramme de sequence systeme de Traiter les demandes 



V 



Les principales operations systeme pour les cas d'utilisation Demander une 
formation et Traiter les demandes sont done listees sur les deux schemas pre- 
cedents (Heches entrant dans le SGDF). 

Etape 11 - Contrats d'operations (iterations #2 et #3) 




Exercice 7-24. 

Contrats d'operations systeme 



Utilisez le plan type precedent de contrat d'operation systeme. 

Redigez les contrats de validerDemande et refuserDemande. 
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J- 

O 



on 



En premier lieu, nous allons extraire du diagramme de classes du package 
Demandes deformation (voir figure 7-26) la partie concernee par notre ques- 
tion. En effet, les operations systeme validerDemande et refuserDemande 
vont agir sur des objets et des liens emanant du diagramme ci-apres. 



Figure 7-65. 

Extrait du diagramme 
de classes deduit de la 
modelisation metier 




emet 



0..1 




^ traite 




Employe 



Demande de formation 



Responsable formation 




nom 
email 



Desaccord 



Accord 



motif 



Etablissons tout d'abord le contrat de l'operation validerDemande : 

• Nom 
validerDemande . 

• Responsabilites 

Creer une demande initiale d'apres les elements du catalogue et la trans- 
mettre au responsable formation pour instruction. 

• References 

Cas d'utilisation Demander une formation. 

• Pre-conditions 

- le catalogue de formations existe ; 

- l'employe est connecte sur l'intranet ; 

- un objet e representant l'employe existe dans 1' application. 

• Post-conditions 

- une demande de formation ddf a ete creee ; 

- les attributs dateValidite et dateEmission de ddf ont ete initialises ; 

- ddf a ete liee a l'employe e ; 

- ddf a ete liee a un element du catalogue de formation (c'est un aspect qui 
faisait defaut dans le diagramme de la modelisation metier) ; 

- un e-mail contenant ddf a ete transmis au responsable formation. 
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• Exceptions 

- L'employe peut annuler sa creation de demande a tout moment avant de 
valider. 

Poursuivons par le contrat de l'operation refuserDemande : 

• Nom 
refuserDemande . 

• Responsabilites 

Refuser une demande transmise par un employe et lui retourner le motif du 
refus. 

• References 

Cas d'utilisation Traiter les demandes. 

• Pre-conditions 

- une demande de formation ddf existe ; 

- le responsable est connecte sur l'intranet ; 

- un objet e representant l'employe existe dans l'application et est relie a ddf. 

• Post-conditions 

- la demande de formation ddf a ete detruite ; 

- un objet Disaccord d a ete cree ; 

- les attributs date et motif de d ont ete initialises ; 

- un e-mail contenant d a ete transmis a l'employe e. 

• Exceptions 

- Neant. 

Etape 12 - Diagrammes d'interaction (iterations #2 et #3) 



Exercice 7-25. 

Diagramme de communication 

Comme a l'etape 8 pour les iterations 1 et 2, nous allons poursuivre notre travail de 
conception en realisant un diagramme de communication. 

Elaborez un diagramme de communication qui realise vauderDemande. 



^ La demarche est analogue a celle que nous avons adoptee pour 1 'exercice 7-20. 
O Le diagramme de communication representant 1' initialisation de la demande de 
formation par l'employe est tout a fait similaire a celui de la figure 7-44. 
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1 . creerDemandeFormationf 



: EcranGeneralEmploye 



Figure 7-66. 

Diagramme de communication 
de V initialisation de ddf 




ddf : DemandeDeFormation 



1 . activerf ) 



2.1.1. create(emp) 



2. initialiser)) 



2.1.initialiserDemande(emp) 




: EcranDemandeFormations 



: CdntroleurDemandesFormations 



Continuons par l'etablissement du lien avec un element du catalogue de for- 
mation, puis par le positionnement des attributs dateValidite et dateEmission, 
et enfin l'envoi du message au responsable. 



: Responsable 
Formation 



4.1 .1 .1 . nouvelle demande (emp,element,dateEmission) 



1.creerDemandeFormation( ) 



EcranGeneralEmploye 



Figure 7-67. 

Diagramme de 
communication 
complet de 
V operation 
systeme 

validerDemande 





emp : Employe 



ddf: 

DemandeDeFormation 



: Employe 



2. initialise^ ) 

3. selectionnerfelement) 

4. validerfdateValidite) 



2.1 . initialiserDemande^mp) 
3.1 . lierDemande(element) 
4.1 . validerfdateValidite) 



A 2.1.1 
3. 

I 4.1. l.v 



create (emp) 
1 .1 .lier(element) 
valider£JateValidite) 



: EcranDemandeFormation : ControleurDemandesFormations 



Etape 13 - Diagrammes de classes de conception 
(iterations #2 et #3) 



EXERCICE 7-26. 

Diagramme de classes de conception 



Sur le modele de la figure 7-62 et en extrapolant a partir de la reponse precedente mais 
aussi en vous appuyant sur votre connaissance du sujet, realisez un diagramme de 
classes de conception du package Demandes. 
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Vous pouvez vous referer egalement au diagramme d'etats de la question 7-15. 
Elaborez le diagramme de classes de conception du package Demandes. 



J- 

O 



on 

Nous avons deja passe en revue les subtilites du diagramme de classes aux 
chapitres 3 et 4. La classe d'association Inscription ne vous surprendra done 
pas. On notera la facon dont nous avons complete le compartiment operations 
de la classe DemandeDeFormation, en particulier avec les operations privees, 
necessaires pour l'envoi des messages aux acteurs. 

On notera encore que nous avons fait figurer dans le diagramme les classes 
Session et ElementCatalogue bien qu'elles n'appartiennent pas au package 
courant. En effet, il est important de montrer leurs relations avec des classes 
du package Demandes pour justifier ensuite le sens des dependances entre les 
packages englobants. Precisement, il ne faut representer que les associations 
navigables, les dependances ou les generalisations qui pointent vers les clas- 
ses externes a celles du package concerne. 



Figure 7-68. 

Diagramme 
de classes 
de conception 
du package 
Demandes 



«entity» 
Employe 



nom : String 
prenom : String 
service : String 
fonction : String 
email : Email 



A 



1 



-demandeur 



«entity» 
DemandeDeFormation 



■ dateEmission : Date 

■ dateValidite : Date 



- Iier(element : ElementCatalogue) 

- valider( dateValidite : Date) 

- refuser() 

- accepter{) 

- choisirSession(s : Session) 

- finSession() 

- annulerQ 

■ annulerSession(s : Session) 
emettre(dateEmission : Date) 
amettreRefus(motif : String) 
3mettreAccord{) 
pmettreCommandeQ 



operations 
- privees 



«entity» 
Inscription 



date : Date 



annulerQ 



est satisfaite par 



«entity» 
Reponse 



;<ent ty» 
Accord 



«entity» 
Session 
(from Catalogue) 



«parameter: 



«entity» 
Elemen tCa talogue 
(from Catalogue) 



«ent ty» 
Desaccord 



- motif : String 
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Etape 14 - Retour sur I'architecture 

Exercice 7-27. 
Diagramme de packages 



Reprenez la figure 7-36 qui representait I'architecture en couches du systeme et montrez 
toutes les classes que nous avons identifiees a l'interieur des packages correspondants. Ne 
tenez pas compte de la couche services techniques, pas plus que des classes de base Java. 

Completez le diagramme de packages d'architecture. 



^5 II suffit de recenser toutes les classes que nous avons utilisees dans nos diffe- 
O rents diagrammes, et de les representer a l'interieur du package adequat. 



L' architecture logique detaillee des trois premieres couches est montree sur la 
figure suivante. 



Figure 7-69. 

Detail de V architecture en 
couches des trois premieres 
iterations 



IHM Responsable formation 

+ EcranContenu 
+ EcranGeneralResponsable 
+ EcranFormation 
+ EcranSessions 



«layer» 
Presentation 



IHM Employe 



+ EcranGeneralEmploye 
+ EcranDemandeFormation 



1A. 



«layer» 
Logique applicative 

+ ControleurFormations 
+ ControleurOrganismes 
+ ControleurThemes 
- ControleurDemandesFormations 



I 
I 

V 



Comptabilite 

+ Facture 
+ Paiement 



«layer» 
Logique metier 



-5> 



Catalogue 

+ Theme 
+ Formation 

+ Session 
+ Organisme 
+ Catalogue 

+ Contenu 
- ElementCatalogue 



Demandes 



+ Employe 
- DemandeDeFormation 
+ Inscription 
+ Reponse 
+ Accord 
+ Desaccord 
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Etape 15 - Passage au code objet 



Les modeles de conception que nous avons realises permettent de produire, d'une 
maniere aisee, du code dans un langage de programmation objet tel que Java ou C# : 
• Les diagrammes de classes permettent de decrire le squelette du code, a savoir 
toutes les declarations. 



PRODUCTION DU SQUELETTE DE CODE JAVA (OU C#) 
A PARTIR DES DIAGRAMMES DE CLASSES 

En premiere approche : 

- la classe UML devient une classe Java (idem en C#) ; 

- les attributs UML deviennent des variables d'instances Java (idem en 
C# c ); 

- les operations UML deviennent des methodes Java (idem en C#). 

On notera que les roles navigables produisent des variables d'instances, 
tout comme les attributs, mais avec un type utilisateur au lieu d'un type 
simple. Le constructeur par defaut est implicite. 




public class Livre 



private String titre; 

*" private String ISBN; 

private Date da te Pa rut ion ; 

■^■private Adherent emprunteur; 



publ ic Livre ( ) 

Constructed 



■►public Date getDateRetour ( ) 



Figure 7-70. 

Squelette du code Java de la classe Livre 



c. On peut egalement utiliser le concept C# de property, qui permet une meilleure encapsulation. Attention, le 
concept d'attribut existe en C#, mais ne signifie pas du tout la meme chose qu'en UML ! 
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• Avec les diagrammes d' interaction, il est facile d'ecrire le corps des methodes, en 
particulier la sequence d'appels de methodes sur les objets qui collaborent. 



A retenir PRODUCTION DU CORPS DES METHODES 

A PARTIR DES DIAGRAMMES D'INTERACTION 




Figure 7-71. 

Corps de la methode enregistrerEmpmnteur en Java (idem en C# !) 



EXERCICE 7-28. 

Production d'un squelette de code Java 

A partir de la figure 7-68, proposez un squelette de code Java pour la classe Demande- 
DeFormation. 

Ecrivez le squelette Java de la classe DemandeDeFormation. 



Reprenons le schema 7-68 en enlevant ce qui ne concerne pas la classe 
"o DemandeDeFormation. Les regies precedentes suffisent pour produire le 
vT* squelette de la classe en Java. La seule difficulte tient a ce qu'il ne faut pas 
oublier la directive d'importation pour les relations avec les classes qui appar- 
tiennent a d'autres packages, ainsi que pour les classes de base Java. 
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Figure 7-72. 

La classe 
DemandeDe 
Formation etse s 
relations 



«entity» 
Employe 



nom : String 
prenom : String 
service : String 
fonction : String 
email : Email 



«entity>> 
Session 
(from Catalogue) 



1 -demandeur 



«entity>> 
Inscription 



annulerQ 



<<entity» 
Demand eDeFormation 



dateEmissiotn: Date 
dateValidite \Date 



+ lier(element : Element_C_atalogue) 
+ valider(dateValidite(f Date)) 
+ refuse r() 
+ accepte r() 

+ choisirSession(s : Session) 
+ finSessionf) 
+ annulerQ 

+ annulerSessionfs : Sessiojil 

- emettre(dateEmissionjiftfe)J) 

- emettreRefusfmotif f St ring)) 

- emettreAccord() 

- emettreCommande() 



est satisfaite par 



«paramete 



0..1 



<<entity» 
Element Catalogue 
{from Catalogue) 



0..1 



<<entity» 
Reponse 



date : Date 



Le code Java correspondant est montre sur le schema suivant. 

On remarquera les directives d' importation ainsi que les quatre dernieres 
methodes qui permettent Faeces en lecture (get) et en ecriture (set) aux attri- 
buts, pour respecter le principe d'encapsulation. 



Etude de cas complete : de la modelisation metier a la conception detaillee en Java ou C# 

Chapitre 7 



package demands s ; 



.mport java . util . * ; 
import catalogue . Session; 
'.mport catalogue . ElementCatalogue 




public class DemandeDeFormation 

{ 

private Date dateEmission; 

private Date dateValidite; 

pri va t e Empl oye demandeur ; 

private Inscription inscription; 

private ElementCatalogue elementCatalogue ; 

private Reponse reponse ; 

public DemandeDeFormation () 



public void lier ( ElementCatalogue element) 



public void valider (Date dateValidite) 



public void refuser () 



public void accepter () 



public void choisirSession (Session s) 



public void finSession ( ) 



public void annuler() 



public void annulerSession (Session s) 



pri vate voi d emet t re ( Da te dat eEmission ) 



private void emettreRefus (String motif) 



private void emettreAccordf) 



private void emettreCommande ( ) 



public Date getDateEmission( 
return dateEmission; 

public void setDateEmission (Date de) 
dateEmission = de; 

public Date getDateValidite () 
return dateValidite; 

public void setDateValidite (Date Av) 
dateValidite = dv: 



Figure 7-73. 

Squelette de code Java de la classe DemandeDeFormation 



EXERCICE 7-29. 

Production d'un squelette de code C# 



Pour bien montrer que notre conception permet ensuite facilement de deliver du code 
dans n'importe quel langage objet, faites le meme exercice que precedemment, mais en 
utilisant le langage C# (de la plate-forme .NET) plutot que Java. 



Ecrivez le squelette C# de la classe DemandeDeFormation. 
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private DateTime DateEmission; 

private DateTime DateValidite; 

private Employe Demandeur; 

private Inscription Inscr; 

private ElementCatalogue ElementCat ; 

private Reponse Rep ; 

public DemandeDeFormat ion ( > 



public void Lier ( ElementCatalogue Element) 



public void Valider (DateTime DateValidite) 



public void Refuser ( ) 



public void Accepter () 



public void ChoisirSession (Session S) 



public void FinSession() 




public void Annuler () 



public void AnnulerSession (Session S) 



rivate void Emettre (DateTime DateEmission) 



rivate void EmettreRef us {string Motif) 



rivate void EmettreAccord { ) 



rivate void EmettreCommande () 



public DateTime getDateEmiss^pn ( ) 
return DateEmission ; 

public void setDateEmission (DateTime \De) 
DateEmission = De; 

public DateTime get DateValidite ( ) 
return DateValidite; 

public void setDat eValidite (DateT^e Dv) 
DateValidite = Dv; 



Figure 7-74. 

Squelette de code C# de la classe DemandeDeFormation 



Notez qu'en C#, on utiliserait probablement la notion de propriete {property) 
pour coder les accesseurs de fagon plus elegante, par exemple : 

public DateTime DateValidite 



{ 



get { return m_D at eValidite; } 
set { m_DateValidite=value; } 
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EXERCICE 7-30. 

Production d'un squelette de code Java (bis) 

A partir de la figure 7-62, proposez un squelette de code Java pour la classe Formation. 
Ecrivez le squelette Java de la classe FORMATION. 

O Reprenons le schema 7-62 en enlevant ce qui ne concerne pas la classe Formation. 

O Quelques difficultes supplementaires apparaissent, par rapport a la question 
precedente : 

• la relation de generalisation avec ElementCatalogue , 

• les multiplicites « 1„* » avec Theme et « 0..* {ordered} » avec Session. 



Figure 7-75. 

La classe Formation 
avec ses relations 



«entity» 
ElementCatalogue 




dateDebut : Date 
lieu :Adresse 




«entity» 
Formation 



titre : String 
duree : short 
prix : int 



creerContenu(audience : String, prerequis : String, objectifs : String, outils : String, plan : String) 
creerSession( dateDebut : Date, lieu : String) 
valider(theme : Theme) 

modifierContenu(audience : String, prerequis : String, objectifs : String, outils : String, plan : String) 
moditierSession( dateDebut : Date, lieu : String) 
modifierTheme(theme : Theme) 
annulerSessionQ 



1 



«entity» 

Omaoisms 



nom : String 
adresse : String 
numTel ; Numero 
numFax : Numero 
email : Email 



«entity» 
Contenu 



audience : String 
prerequis : String 
objectifs : String 
outils : String 
plan : String 



Les regies precedentes ne suffisent plus. Nous avons vu un exemple de trans- 
formation d'une association navigable de multiplicite « 1 » (ou « 0..1 »), mais 
comment traduire les associations navigables de multiplicite « * » ? 
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A retenir TRADUCTION EN JAVA DES ASSOCIATIONS AVEC MULTIPLICITE "*" 

Le principe en est relativement simple : une multiplicity «*» va se 
traduire par un attribut de type collection de references d'objets au lieu 
d'une simple reference sur un objet. 

La difficulty consiste a choisir la bonne collection parmi les tres 
nombreuses classes de base que propose Java. Bien qu'il soit possible de 
creer des tableaux d'objets en Java, ce n'est pas forcement la bonne 
solution. En la matiere, on prefere plutot recourir a des collections, 
parmi lesquelles les plus utilisees sont ArrayList (anciennement Vector) 
et HashMap (anciennement HashTable). Utilisez ArrayList si vous devez 
respecter un ordre et recuperer les objets a partir d'un indice entier ; 
utilisez HashMap si vous souhaitez recuperer les objets a partir d'une 
cle arbitraire. 

Attention, le JDK 1.5 introduit les collections typees appelees 
« generics » d . Nous allons pouvoir declarer dorenavant des listes de 
sessions et des maps de themes, comme illustre a la question suivante. 

Voici quelques exemples des solutions a retenir pour effectuer un choix 
pertinent : 



A1 





\ B1 




\ 1 





A2 








B. 


1 


k * 




public class Al 

private Bl leBl; 



public class A2 

private B2 les B2 [ ] ; 



public class A3 



private List<B3> lesB3 
= new ArrayList<B3> ( ) ; 



public class A4 



private Map<Q,B4) lesB4 
= new HashMap<Q, B4> ( ) ; 



Figure 7-76. 

Traductions possibles des associations en Java 1 .5 



d. Comme on pouvait s'y attendre, le langage C# ne sera pas en reste dans la version 2.0 du Framework .NET ! 
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Pour la classe Formation, nous allons utiliser : 

• une ArrayList pour 1' association ordonnee avec la classe Session ; 

• une HashMap pour l'association avec la classe Theme, plutot qu'un simple 
tableau : nous nous servirons du nom de theme comme qualificatif . 

Toutes ces explications nous conduisent au code suivant pour la classe Formation. 



Figure 7-77. 

Squelette de code 
Java 1 .5 de la classe 
Formation 



package cataloguer- 
import j ava . util . * . 



public cl as ^Formation extends ElementCatalogua) 




private String titre; 
private short chiree ; 
private int prix; 



lst<bession> sessions = new ArrayList<Session^ 
Ci vate Map<String f Theme> themes = new HashMap<String f T heme >_ U^; 
private CTo 1 1 L ti 1 1 U — uun Lenu? " 1 

private Organisme organisme ; 

public Formation ( ) 



public void creerContenu (String audience. String prerequis, 
String ob j ectif s , String outils. String plan) 



public void creerSession (Date date Debut, String lieu) 



public void valider( Theme theme) 



public void modif ierContenu (String audience, String prerequis. 
String obj ectif s, String outils, String plan) 



public void modif ierSess ion (Date date Debut, String lieu) 

public void modifier Theme ( Theme theme) 

public void annulerSession ( ) 

public String getTitre ( ) {return titre ; } 
public void setTitre (String t) {titre = t; } 
public short getDuree ( ) {return duree ; } 
public void setDu ree (short d) {duree = d; } 
public int getPrix() {return prix;} 
public void setPrix ( int p) {prix = p; } 
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EXERCICE 7-31. 

Production d'un squelette de code C# (bis) 



on 



Ecrivez le squelette C# de la classe Formation. 



A retenir TRADUCTION EN C# DES ASSOCIATIONS AVEC MULTIPLICITY "*" 

Le principe est identique a Java : une multiplicite « * » va se traduire par 
un attribut de type collection de references d'objets au lieu d'une simple 
reference sur un objet. 

Comme en Java, on prefere recourir a des collections, parmi lesquelles 
les plus utilisees sont ArrayList, SortedList et HashTable. Utilisez Array- 
Lists] vous devez respecter un ordre et recuperer les objets a partir d'un 
indice entier ; utilisez HashTable ou SortedList si vous souhaitez recu- 
perer les objets a partir d'une cle arbitraire. 

Voici quelques exemples des solutions a retenir pour effectuer un 
choix pertinent : 



Al 








B1 




1 









A2 




> 




""ft 



Figure 7-78. 

Traductions 
possibles des 
associations 
en C# 




public class Al 

private Bl leBl; 



public class A2 

private B2 lesB2[],- 







A3 




r > 


) B3 




\ *j 



public class A3 



private List lesB3 
= new ArrayList () ; 



A4 


qualificatif 




B4 





private HashTable lesB4 
= new HashTable { ) ; 



II est a noter que les collections parametrees sont annoncees egalement 
dans la prochaine version de C# (.NET 2.0). Le troisieme cas donnerait 
par exemple une liste generique comme suit : 

public class A3 

{ 

private List<B3> lesB3 = new ArrayList<B3> () ; 
} 
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Pour la classe Formation, nous allons utiliser : 

• une ArrayList pour V association ordonnee avec la classe Session ; 

• une HashTable pour l'association avec la classe Theme, plutot qu'un simple 
tableau : nous nous servirons du nom de theme comme qualificatif . 

Toutes ces explications nous conduisent au code suivant pour la classe Formation. 



Figure 7-79. 

Squelette de code C# de la classe 
Formation 



namespace Catalogue ; 



using Syste: 
public classi 



^fo^mation 



Element Cat alogu 




private string Titre; 
private short Duree; 
private int Prix: 



lvate List Sessions = new ArrayList () ; 
vate HashTable Themes = new HashTable (); 



private Contenu C6nC; 
private Organisrae Org; 



public Formation ( ) 



public void CreerContenu (string Audience, string Prerequis, 
string Objectifs, string Outils, string Plan) 



public void CreerSession (DateTime DateDebut, string Lieu) 



public void Valider ( Theme T) 



public void ModifierCont enu (string Audience, string Prerequis, 
string Objectifs, string Outils, string Plan) 



public void Modif ierSession (DateTime DateDebut, string Lieu) 

public void Modif ierTheme ( Theme T) 

public void AnnulerSession ( ) 

public string getTitre() {return Titre;} 
public void setTitre (string T) {Titre = T; ) 
public short getDuree() {return Duree;} 
public void setDuree ( short D) (Duree = D;} 
public int getPrix() (return Prix;} 
public void setPrix(int P) {Prix = P;} 
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Etape 16 - Deploiement de I'application 



Nous allons finalement decrire l'implantation physique de notre application de gestion 
des demandes de formation grace a un dernier type de diagramme propose par UML : le 
diagramme de deploiement. 



A retenir DIAGRAMME DE DEPLOIEMENT 

Le diagramme de deploiement montre la configuration physique des 
differents materiels qui participent a I'execution du systeme, ainsi que 
les artefacts qu'ils supportent. 

Ce diagramme est constitue de « nceuds » connectes par des liens physi- 
ques. Les symboles des noeuds peuvent contenir des artefacts (et non 
plus des composants comme en UML 1). 

ARTEFACT 

Un artefact modelise une entite physique comme un fichier. On le 
represente par un rectangle contenant le mot-cle « artifact ». On 
explicite la presence d'un artefact sur un noeud de deploiement en 
imbriquant son symbole dans celui du noeud englobant. 

Si un artefact implements un composant ou une classe, on dessine une 
fleche en pointilles avec le mot-cle « manifest » allant du symbole 
de I'artefact au symbole du composant qu'il implemente e . 



"artifacts 
Artifacti 



Componentl 



I] 



Figure 7-80. 

Notation du diagramme de deploiement en UML 2 



e. Le diagramme de deploiement a ete notablement modifie avec la nouvelle version UML 2. Ceci vient princi- 
palement de la redefinition du concept de composant, plus logique en UML 2 et done moins physique. L'intro- 
duction du nouveau concept d'artefact (artifact) permet de mieux separer la manifestation physique du 
composant de sa representation logique. 
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EXERCICE 7-32. 

Diagramme de deploiement 

Proposez un diagramme de deploiement realiste pour les trois premieres iterations du 
sy steme de gestion des demandes de formation. 

Elaborez un diagramme de deploiement pour les trois premieres iterations. 



on 



O Chaque acteur a son propre poste client qui est un « PC » connecte au serveur 
"o intranet de l'entreprise, lequel est lui-meme un PC serveur NT. Ce serveur 
v5^ intranet contient en particulier l'application d'authentification. 

Chacun des deux acteurs a en outre sa propre interface homme-machine, materia- 
lisee par une page JSP. Ces deux JSP utilisent un meme service d'authentification 
general, contenu par le serveur intranet. Le catalogue est stocke dans une base de 
donnees specifique, de meme que les employes. 

Le serveur metier heberge pour sa part les autres applications ainsi que les bases 
de donnees. II s'agit la d'une machine Unix et ce pour des raisons historiques. . . 

Le dessin, realise avec l'outil Enterprise Architect qui fournit ses propres icones 
pour les differents types de nceud, est dome a titre d'exemple sur la figure suivante. 



dd Deploiement ^ 



Poste du responsable 



Poste de I'employe 

«jsp page» |7j 
IHM Employe 



Serveur intranet 



process" 
Authentifi cation 



Serveur metier 



« process » 
Gestion catalogue 



"process" 
Gestion demandes 



"table» 
Employes 



Figure 7-81. 

Diagramme de deploiement correspondant 
aux trois premieres iterations 
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Etudes de cas 
complementaires 



O 



\es 



■ Operation systeme ■ Diagramme de communication 

■ Diagramme de sequence ■ Methode ■ Typage ■ 
Navigabilite des associations ■ Dependances entre 
classes ■ Collection d'objets ■ Java ■ C# ■ Design 
pattern. 



Ce chapitre va nous permettre de completer au moyen 
d'autres etudes de cas notre panorama des techniques de 
modelisation UML, en insistant sur celles mises en ceuvre 
durant I'activite de conception, en particulier : 

• Les diagrammes d'interaction ; 

• Les diagrammes de classes. 

Nous apprendrons egalement a utiliser certains design 
patterns supplementaires. 
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Etude du systeme d'information d'une bibliotheque 



Nous allons partir d'un modele d'analyse d'un systeme informatique qui doit permettre 
de gerer une bibliotheque. Cette bibliotheque ne prete que des livres dans un premier 
temps. 

Le diagramme de classes d'analyse est montre sur la figure suivante. 



Figure 8-1. 

Diagramme de classes 
d'analyse du SI. 
de la bibliotheque 



enregistre 



Bibliolhecaire 



nom 
prenom 



traite 



0..1 



lePretCourant 



Pret 



date 
/ dateRetour 



emploie 



/ concerne 



Bibliotheque 



connait 



Adherent 




nom 

prenom 

numero 



emprunte 



0..1 



0..3 



Livre 



titre 

auteur 

ISBN 



1 


Catalogue 


decrit 











Le diagramme de cas d'utilisation provisoire est presente ci-apres. 



Figure 8-2. 

Diagramme de cas 
d'utilisation preliminaire 
du SJ. de la bibliotheque 




Maintenir le catalogue 



Etudes de cas complementaires 



Chapitre 8 



Poursuivons par les operations systeme du cas d'utilisation Enregistrer les emprunts qui 
sont detaillees sur le diagramme de sequence systeme suivant. 



Use Case : Enregistrer les emprunts 

Scenario nominal : 

3. Le bibliothecaire enregistre 
I'identifiant de I'adherent. 

5. Le bibliothecaire enregistre 
le numero de chaque 
document. 

7. Le bibliothecaire demande 
I'edition d'un bulletin de pret. 



Figure 8-3. 

Operations systeme du cas 
d'utilisation Enregistrer les emprunts 



:Bibliothecaire 



indiquerEmprunteur(id) 



emprunterLivre(ISBN) 



editerBulletinDePretf) 



:Systeme 



Nous allons ensuite nous interesser au contrat de l'operation emprunterLivre . Notez que 
nous passons sous silence la premiere operation indiquerEmprunteur, mais uniquement 
parce qu'elle est moins riche que la deuxieme et n'apporterait rien a notre etude. Dans la 
realite, les operations systeme doivent bien sur etre con9ues par ordre chronologique. 

• Nom 

emprunterLivre (ISBN). 

• Responsabilites 

Enregistrer l'emprunt d'un livre identifle par son numero ISBN. 

• References 

Cas d'utilisation Enregistrer les emprunts. 

• Pre-conditions 

- le catalogue de livres existe et n'est pas vide ; 

- I'adherent a ete reconnu par le systeme et n'a pas atteint le seuil maximal 
d' emprunts. 

• Post-conditions 

- un pret p a ete cree ; 

- l'attribut date de p a ete positionne a la date du jour ; 

- l'attribut dateRetour de p a ete positionne a (la date du jour + deux semaines) ; 

- p a ete lie au livre 1 dont l'attribut ISBN vaut 1'ISBN passe en parametre ; 

- p a ete lie a I'adherent concerne et a la bibliotheque. 
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CONCEPTION DU COM PORTE ME NT (DIAGRAMMES D'INTERACTION) 

EXERCICE 8-1. 

Diagramme de communication de conception 



Developpez un diagramme de communication pour l'operation systeme emprunterLivre 
a partir des informations precedentes. 

Detaillez chacune de vos decisions de conception. 

Ne vous preoccupez pas des classes d'interface («boundary») . 

Developpez un diagramme de communication pour emprunterLivre. 

<>° n 

Notre diagramme de communications demarre par la reception d'un message 
"o systeme venant d'un acteur. Puisque la possibilite nous est donnee de ne pas 
nous preoccuper des objets d'interface, nous allons directement choisir un 
objet qui traitera cet evenement systeme. 



systeme vu 
comme une 
boTte noire 



2 



: Bibliothecaire 

emprunterl_ivre(ISBN 



: Systeme 



: Bibliothecaire 




[ 



emprunterl_ivre(ISBN ) 




► 


► 


< 



Figure 8-4. 

Passage de I 'analyse a la conception 



La solution que nous avions mise en ceuvre au chapitre precedent (etape 6) 
nous amenait a introduire un objet artificiel de conception de type 
« controleur » que nous aurions pu appeler ici ControleurEmprunts . 

En fait, dans le cas d'un systeme comprenant un nombre restreint d'opera- 
tions systeme, une approche plus simple est possible, qui n'oblige pas a ajou- 
ter une nouvelle classe. Cette solution consiste a utiliser comme controleur 
une instance d'une classe d'analyse existante : 

• soit un objet representant le systeme entier ou l'organisation elle-meme ; 

• soit un objet representant un role qui aurait realise l'operation systeme. 
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Le premier choix possible est le plus direct, mais son inconvenient majeur, 
c'est que Ton affecte le traitement de toutes les operations systeme a un objet 
unique, qui risque rapidement d'etre surcharge en matiere de responsabilites. 
C'est une solution acceptable dans notre exemple, et la classe candidate est la 
classe Bibliotheque . 

La seconde possibilite permet en general de repartir les operations systeme sur 
plusieurs objets. Mais ici la seule classe candidate est la classe Bibliothecaire , 
ce qui n'apporte rien par rapport a la solution precedente. Nous conservons 
done Bibliotheque comme objet controleur pour notre operation systeme. Le 
diagramme de communication peut done demarrer de la maniere suivante. 



Figure 8-5. 

Diagramme de communication 

de V operation emprunterLivre (debut) 




Comment devons-nous maintenant proceder ? II faut tout simplement etudier 
le contrat d' operation. Rappelez-vous cependant que les post-conditions 
repertoriees dans le contrat ne sont pas forcement ordonnees. Dans notre cas, 
il semble quand meme raisonnable de commencer par la creation de l'objet 
pret puisque les autres post-conditions s'appliquent a ses attributs ou a ses 
liens. 

La question qui se pose alors est la suivante : quel objet doit avoir la respon- 
sabilite de la creation du pret p ? 

Si nous revenons au diagramme de classes d'analyse, nous constatons que 
quatre classes possedent deja une association avec la classe Pret, a savoir : 
Bibliothecaire, Bibliotheque, Livre et Adherent. Elles sont done toutes de 
bonnes candidates initiales. Cependant, le meilleur choix est en general 
fourni par la classe qui possede une association de type composition, agrega- 
tion ou « enregistre ». Dans notre exemple, la classe Bibliotheque est juste - 
ment liee a Pret par une association « enregistre ». Comme, en outre, la 
Bibliotheque est deja le controleur, elle constitue le candidat ideal. 

Le diagramme de communication devient alors : 



Figure 8-6. 

Diagramme de 
communication de 
I 'operation 
emprunterLivre 
(suite) 



1 . emprunterLivre(ISBN) 



: Bibliotheque 



create 



p : Pret 



: Bibliothecaire 
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On notera l'utilisation deroutante au premier abord du message en anglais 
create. En effet, en toute rigueur, l'objet p ne peut pas recevoir le message 
create, puisqu'il n'existe pas encore ! II s'agit la d'une bonne pratique qui 
evite d'entrer dans des considerations qui dependent du langage de program- 
mation cible. En Java (ou en C#), ce message de creation se traduira proba- 
blement par le mot-cle new et l'appel du constructeur de la classe Pret, qui 
retournera une reference sur le nouvel objet. 

Ainsi, la bibliotheque a maintenant une reference sur l'objet p nouvellement 
cree. Notez que, puisque le message de creation renvoie toujours une refe- 
rence sur le nouvel objet, nous ne montrons pas le retour explicitement, bien 
que cela soit legal. On obtiendrait une representation un peu plus lourde telle 
que celle qui est illustree par la figure suivante. 



Figure 8-7. 

Diagramme de 
communication de 
I 'operation 
emprunterLivre 
(suite alternative) 



1 . emprunterLivre(ISBN) 



1.tp = 



create 





: Bibliotheque 




p : Pret 







: Bibliothecaire 



Poursuivons notre reflexion. Les attributs date et dateRetour ne pourraient-ils 
pas etre positionnes par l'objet p des sa creation, suite a la recuperation de la 
date du jour par une methode que nous ne detaillerons qu'en conception 
detaillee ? 

C'est ce que nous representons sur le diagramme de communication suivant. 



Figure 8-8. setDate(dateDuJour) 



Diagramme de 
communication 
de V operation 
emprunterLivre 
(suite 2) 




: Bibliothecaire 



Remarquez une fois de plus (voir chapitre 7, etape 8) l'utilisation de la notation 
decimale des numeros de messages, qui permet de representer l'imbrication des 
messages. On notera egalement l'utilisation de la boucle au-dessus de l'objet 
qui symbolise un lien de l'objet vers lui-meme comme support d'un message 
« a soi-meme ». 
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Le diagramme de sequence correspondant (avec la notation des « focus of 
control ») est dorrne ci-apres en comparaison. 



Figure 8-9. 

Diagramme de 
sequence de 
I 'operation 
empmnterLivre 
(suite 2) 



: Bibliothecaire 



: Bibliotheque 



JL emprunterLivre(ISBN) 



create 



p : Pret 



I 




Revenons a l'etablissement du contrat de l'operation. Que devons-nous faire 
maintenant ? II nous faut un lien avec le livre dont l'attribut ISBN vaut 
1'ISBN passe en parametre de l'operation empmnterLivre. 

Quel objet est-il le mieux place pour trouver un livre en fonction de son 
ISBN? 

Reprenons le diagramme de classes d'analyse (figure 8-1) : la classe Catalogue 
est la candidate ideale, puisque le catalogue connait tous les livres. Mais quel 
objet doit-il lui formuler la demande ? Ce sera soit le pret p, soit la bibliotheque, 
d'apres notre diagramme de communication. 

Pour respecter le principe de faible couplage, il vaut mieux que la bibliotheque 
s'en charge, car elle possede deja une association avec le catalogue, contraire- 
ment au pret. De plus, il est fort probable que la bibliotheque doive collaborer 
avec le catalogue dans le cadre d'autres operations systeme, par exemple lors de 
l'ajout de nouveaux livres. II faut done que la bibliotheque ait un lien perma- 
nent avec le catalogue, ce qui n'est pas du tout le cas du pret. Toutes ces raisons 
font clairement pencher la balance en faveur de la bibliotheque. 

On notera que cela suppose que les objets catalogue et bibliotheque soient 
crees lors de 1' initialisation du systeme et qu'un lien de visibilite soit etabli 
entre eux. II est courant en conception objet de travailler d'abord sur les colla- 
borations entre objets « metier », puis de traiter dans un second temps le pro- 
bleme plus technique de 1' initialisation du systeme informatique. Cela permet 
de s'assurer que les bonnes decisions d'affectation de responsabilites aux 
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objets dans le contexte des collaborations metier contraignent bien l'initiali- 
sation et pas le contraire. 

Revenons a notre choix de communication entre la bibliotheque et le catalogue. 
Comment nommer le message ? Appelons-le chercherLivre , avec un numero 
ISBN en parametre, et comme retour une reference livre sur le bon objet livre. 

Le diagramme de communication modifie est presente ci-apres. 



Figure 8-10. 

Diagramme de comunication de V operation 
emprunterLivre (suite 3) 



1.1.1. setDate(dateDuJour) 
1.1.2. setDateRetour(dateDuJour+14) 



1 . emprunterLivre(ISBN) 



: Bibliotheque 



p : Pret 



1.2. livre = chercherLivre(ISBN) 



: Catalogue 



Que se passe-t-il si le catalogue ne parvient pas a trouver un livre dont 1'ISBN 
correspond a celui recherche ? Ne faut-il pas plutot attendre d' avoir obtenu 
cette reference livre pour effectuer la creation du pret p ? 

C'est tout a fait cela et, pour ce faire, il suffit simplement de permuter l'ordre 
des deux messages, comme cela est represente sur la figure suivante. On 
notera que la numerotation decimale des messages d'affectation des attributs 
est mise a jour en consequence. 

Figure 8-11. 

Diagramme de communication de 
emprunterLivre (suite 3 corrigee) 

1 . emprunterl_ivre(ISBN} 



: Bibliothecaire 



1 .2.1 . setDate(dateDuJour) 
1 .2.2. setDateRetour{dateDuJour+14) 



1.2. create 



: Bibliotheque 




p : Pret 





1.1 . livre = chercherLivre(ISBN) 




: Catalogue 
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Sur le diagramme de classes, il y a une association « 1 - * » entre Catalogue et 
Livre. Cela implique que le catalogue va utiliser une collection d'objets livres, 
probablement implementee en Java sous la forme d'une HashMap. Nous avons 
deja donne les regies de traduction des multiplicites d'associations en collections 
Java au chapitre precedent (figure 7-76). Nous y avons egalement explique l'utili- 
sation du concept de « multi-objet » dans les diagrammes de communication 
pour eviter justement de prendre trop tot des decisions de conception detainee 
(voir figure 7-47). C'est la solution que nous allons aussi adopter ici, mais en uti- 
lisant la notation UML 2 qui remplace le multi-objet UML 1 , a savoir une ligne 
de vie typee par une collection triee (notee livres : Map<String, Livre>). Le mes- 
sage devient plus generique que chercherLivre, puisque la collection represente 
un objet technique « sur etagere », et non pas un objet metier. 

Le diagramme de communication est complete comme suit : 



Figure 8-12. 

Diagramme de communication de 
I 'operation emprunterLivre (suite 4) 



1 . emprunterLivre(ISBN) 



: Bibliothecaire 



1.1. livre = chercherLivre(ISBN) 



1 .2.1 . setDate(dateDuJour) 
1 .2.2. setDateRetour(dateDuJour+1 4) 




Maintenant que nous avons localise le bon livre et que sa reference a ete retour- 
nee a la bibliotheque, nous pouvons nous en servir pour etablir le lien entre le 
livre et le pret. La solution la plus directe consiste a passer la reference livre en 
parametre au message de creation, comme cela est represente ci-apres. 



Figure 8-13. 

Diagramme de communication de V operation 
emprunterLivre (suite 5) 



1 . emprunterLivre(ISBN) 



: Bibliotheque 



: Bibliothecaire 



1.1. livre = chercherLivre(ISBN) 



: Catalogue 



1 .2.1 . setDate(dateDuJour) 
1.2.2. setDateRetour(dateDuJour+14) 



1.2. creatq^r^^ 



p : Pret 



1.1.1. livre =get(ISBN) 



livres : 
Map<String,Livre> 



Conception 



QUATRIEME P ARTIE 



Reprenons la liste des post-conditions a verifier, en indiquant le numero cor- 
respondant du diagramme de communication precedent : 

• un pret p a ete cree : 1 .2 ; 

• l'attribut date de p a ete positionne a la date du jour : 1 .2.1 ; 

• l'attribut dateRetour de p a ete positionne a (la date du jour + deux 
semaines) : 1.2.2 ; 

• p a ete lie au livre 1 dont l'attribut ISBN vaut l'ISBN passe en parametre : 
1.1 et 1.2 ; 

• p a ete lie a 1' adherent concerne et a la bibliotheque : cela reste a faire. 

II nous faut done realiser la derniere post-condition. Quel objet peut-il connaitre 
1' adherent concerne ? Et d'ailleurs, quand le systeme a-t-il identifie l'adherent ? 

Rappelons-nous que nous traitons actuellement l'operation systeme 
emprunterLivre , mais elle a ete precedee par indiquerEmprunteur, comme 
le schema suivant le rappelle. 



Use Case : Enregistrer les emprunts 

Scenario nominal : 

3. Le bibliothecaire enregistre 
I'identifiant de l'adherent. 

5. Le bibliothecaire enregistre 
le numero de chaque 
document. 

7. Le bibliothecaire demande 
I'edition d'un bulletin de pret. 



:Bibliothecaire 



:Systeme 



- * 

- > 



indiquerEmprunteur(id) 



emprunterLivre(ISBN) 



editerBulletinDePret() 



Figure 8-14. 

Operations systeme du cas d' utilisation Enregistrer les emprunts 



II est done imperatif de penser que, lors de l'operation systeme indiquer 
Emprunteur, la bibliotheque conserve une reference sur l'adherent en c 
ours de traitement. Elle peut done egalement passer une reference sur l'adhe- 
rent au message de creation du pret p. 



Le diagramme de communication devient maintenant 
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Figure 8-15. 

Diagramme de communication de 
I'operation emprunterLivre (suite 6) 



1 .2.1 . setDate(dateDuJour) 
1 .2.2. setDateRetour(dateDuJour+14) 



1 . emprunterLivre(ISBN) 



: Bibliotheque 



: Bibliothecaire 



1 .1 . livre = chercherLivre(ISBN) 



1 



1.2. createdivre, 
|?dhCourant : AdherentJ^U 



p : Pret 



1.1.1. livre = get(ISBN) 



: Catalogue 



livres : 
Map<String,Livre> 



La derniere post-condition stipule egalement qu'un lien doit exister entre la 
bibliotheque et le nouveau pret p. Comme c'est la bibliotheque qui cree p, le 
lien existe deja, au moins de facon transitoire. Cependant, nous pouvons 
remarquer qu'il existe une association « 1 - * » entre les classes Bibliotheque 
et Pret, comme cela est le cas egalement entre Catalogue et Livre. 



Figure 8-16. 

Diagramme de classes 
d'analyse du S.I. 
de la bibliotheque 



enregistre 



Bibliothecaire 



nom 
prenom 



emploie 



Bibliotheque 



"0" 



connait 



Adherent 




nom 
prenom 



emprunte 



0..1 



0..3 



Livre 



titre 

auteur 

ISBN 



Catalogue 



decrit 



Ainsi, par analogie, si la bibliotheque veut conserver une trace durable des 
prets qui ont ete crees, il lui faut egalement gerer une collection, a laquelle 
elle doit ajouter le nouveau pret p. Comme au chapitre 7 (voir figure 7-47), 
nous allons utiliser un message generique add() auquel nous passerons en 
parametre la reference sur le pret p. 



Conception 



QUATRIEME P ARTIE 



Les diagrammes de communication et de sequence complets sont montres 
aux figures suivantes. 



Figure 8-17. 

Diagramme de communication complet 
de V operation emprunterLivre 



1.1.1. livre = get(ISBN) 



: Catalogue 



1.1. livre - chercherLivre(ISBN) 



1 . emprunterLivre(ISBN) 



T 



livres : 
Map<String,Livre> 



1.2.1. setDate(dateDuJour) 
1 .2.2. setDateRetour(dateDuJour+1 4) 



: Bibliotheque 



: Bibliothecaire 



1 .2. create(livre, 
adhCourant : Adherent) 



p : Pret 



1.3.add(p) 



prets : 
List<Pret> 



: Bibliothecaire 




Figure 8-18. 

Diagramme de sequence complet de V operation emprunterLivre 
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CONCEPTION STATIQUE (DIAGRAMMES DE CLASSES ET DE PACKAGES) 

EXERCICE 8-2. 

Diagramme de classes de conception 

Proposez un diagramme de classes de conception qui prenne en compte les resultats de 
la question precedente. 

Developpez le diagramme de classes de conception correspondant... 




C> Par rapport au diagramme de classes d'analyse (figure 8-1), nous pouvons : 
O • ajouter des methodes : les operations systeme traitees par la classe Biblio- 
theque, mais aussi chercherLivre de la classe Catalogue ; 

• typer les attributs, ainsi que les parametres et le retour des methodes ; 

• restreindre la navigabilite des associations d'apres le sens des messages sur 
les liens entre objets du diagramme de communication ; 

• preciser les noms des roles du cote navigable des associations et ajouter des 
qualificatifs ; 

• supprimer les classes et associations inutiles d'apres les diagrammes de 
communication ; 

• decider de transformer les attributs derives en methodes ou les garder en 
tant que donnees membres (ex. : l'attribut derive IdateRetour de Pret est 
devenu la methode getDateRetour) ; 

• ajouter les dependances entre classes suite aux liens temporaires entre objets : 
Bibliotheque depend de Livre car elle recupere une reference sur un objet 
livre d'apres le message 1 .1 du diagramme de communication precedent. 
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Figure 8-19. 

Diagramme 
de classes 
de conception 




Bibliotheque 



iquerEmprunteur(id : in 
emprunterLivre(ISBN : String) 
editerBulletinDePretQ 



-leCatalogue 




numero : m\*\ 



connait 



gere 




enri gistre 




-adherentCourant 



-pretsEnCours 



Adherent 



nom : String 
prenom : String 
numero : int 



Pret 



■ dbte : Date 



- getDateRetour () 



-emprunteur 



0..3 



0..1 



enregis re le pret 



-leLivrePrete 




Livre 


- 1 


tre : String 
uteur : String 
3BN : String 







EXERCICE 8-3. 

Structuration en packages 

Proposez un decoupage du diagramme de classes de conception qui minimise les depen- 
dances. 



Realisez un diagramme de packages d'architecture logique... 



De maniere similaire a l'etude de cas precedente, le catalogue de livres est un 
O candidat naturel a la reutilisation, d'autant qu'aucune relation ne part de 
v5^ l'ensemble de classes Catalogue + Livre. 



Le diagramme de packages decrivant l'architecture logique est done donne 
par le schema suivant. 
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Figure 8-20. 

Diagramme de packages de conception 



Bibliotheque 

+ Adherent 
+ Bibliothecaire 
+ Bibliotheque 
+ Pret 



Catalogue 
+ Catalogue 
+ Livre 



Le diagramme de classes du package Bibliotheque est tres similaire a celui de 
la figure 8-19, mais avec l'indication de localisation des classes sous la forme 
(from XX). 



Figure 8-21. 

Diagramme de classes 
de conception du 
package Bibliotheque 



Bibliotheque 



indiquerEmprunteur{id : int) 
emprunterLivre(ISBN : String) 
editerBulletinDePret() 

3 



-leCatalogue 



1 



connait 



0..1 



-adherents 



0..1 



Adherent 



nom : String 
prenom : String 
numero : int 



em igistre 



0..*. 



-adherentCourant 



-pretsEnCours 



-lesPrets 
{ordered} 



Pret 



date : Date 



■ getDateRetour() : Date 



-emprunteur 



0..3 



0..1 



Catalogue 

(from Catalogue) 



chercherl_ivre(ISBN: String) : Livre 



ISBN : String 



decrit 



0..1 



enregi: tre le pret 



-leLivrePrete 



Livre 

(from Catalogue) 



titre : String 
auteur : String 
ISBN : String 
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EXERCICE 8-4. 

gL» Passage au code Java 

Proposez un squelette de code Java pour la classe Bibliotheque . 
Remplissez le corps de la methode emprunterLivre . 

Codez la classe Bibliotheque en Java... 

<>° n 

Comme on l'a deja explique a l'etape 15 du chapitre 7, le passage du dia- 
"o gramme de classes au squelette de code Java et du diagramme de commu- 
vT 1 nication au corps des methodes est assez direct (notez juste l'utilisation 
des « generics » 1.5). Ainsi, on obtient le fragment suivant du fichier 
« Bibliotheque.java » : 



Figure 8-22. 

Squelette de code Java 1 .5 
de la classe Bibliotheque 




package bibliotheque ; 

import j ava . util . * ; 
import catalogue.*; 

public class Bibliotheque 



private Catalogue leCatalogue; 

private Map<Integer , Adherent> adherents = 

new HashMap<Integer , Adherent> ( ) ; 
private List<Pret> lesPrets = new ArrayList<Pret> ( ) 
private Adherent adherentCourant; 

public Bibliotheque () 

{ 

} 

public void indique rEmprunteu r ( int id) 



{ 



'public void emprunterLivre (String ISBN) 

{ 

Livre livre = leCatalogue. chercherLivre (ISBN) ; 
Pret p = new Pret (livre, adherentCourant); 
lesPrets . add (p) ; 



public void editerBullet inDeP ret ( ) 

{ 



) 

} 
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I EXERCICE 8-5. 

A, Passage au code C# 



Proposez un squelette de code C# pour la classe Bibliotheque . 
Remplissez le corps de la methode emprunterLivre . 

Codez la classe BlBUOTHEQUE en C#... 



^5 Comme pour l'exercice 8-4, on obtient facilement le fragment suivant du 
"o fichier « Bibliotheque.es » : 



Figure 8-23. 

Squelette de code C# 
de la classe Bibliotheque 



namespace Bibliotheque 



using System; 
using Catalogue . *; 

public class Bibliotheque 



private Catalogue LeCatalogue; 

private HashTable Adherents = new HashTable ( ) 
private ArrayList LesPrets = new ArrayList () ; 
private Adherent AdherentCourant ; 

public Bibliotheque () 



public void IndiquerEmprunteur ( int Id) 




public void EmprunterLivre (string ISBN ) 

Livre livre = LeCatalogue . ChercherLivre ( ISBN) 
Pret p = new Pret (Livre, AdherentCourant) ; 
LesPrets . add (p) ; 



public void EditerBulletinDePret ( ) 

{ 
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Analyse et conception du jeu de demineur 



L'objectif de cette etude de cas est de concevoir un jeu de demineur comme celui qui est 
livre avec le systeme d'exploitation Microsoft Windows®. Le but du jeu est de trouver le 
plus rapidement possible toutes les cases du plateau contenant des mines sans les 
toucher. 



Figure 8-24. 

Copie d'ecran dujeu 
de demineur 



Demineur [Zj [x] 




Le jeu est compose d'un plateau rectangulaire, d'un chronometre et d'un compteur de 
mines. Le plateau est un quadrillage de cases. Au debut du jeu, toutes les cases du 
plateau sont couvertes, le compteur de mines indiquant le nombre de mines restant a 
localiser. Le chronometre compte le nombre de secondes ecoulees depuis le debut de la 
partie. La partie commence lorsque la premiere case est decouverte. 

Quand une case est decouverte, son contenu est affiche. Le contenu d'une case peut 
etre : rien, une mine ou un nombre indiquant le nombre de mines presentes dans les 
cases voisines. Les scenarios suivants peuvent se produire lorsqu'une case est decou- 
verte, en fonction de son contenu : 

1 . Un chiffre - II ne se passe rien. 

2. Un blanc - Toutes les cases voisines sont devoilees, a condition qu'elles ne soient pas 
signalees par un drapeau. Si l'une de ces cases voisines ne contient rien, le processus 
de decouverte continue automatiquement a partir de cette case. 

3 . Une mine - Le jeu est termine et le joueur a perdu . 

Si die est toujours couverte, une case peut etre marquee en respectant les regies 
suivantes : 

• Marquer une case qui n'est ni decouverte ni marquee decremente le compteur de 
mines restant a localiser et un drapeau apparait sur la case. II indique que cette 
case contient potentiellement une mine. Une case marquee d'un drapeau ne peut 
pas etre decouverte. 
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• Marquer une case deja signalee d'un drapeau permet de la remettre dans son etat 
initial, a savoir couverte et non marquee. Le compteur de mines est alors incre- 
mente de 1 . 

MODELISATION DES EXIGENCES 



EXERCICE 8-6. 

Diagramme de cas d'utilisation 



Developpez un diagramme de cas d'utilisation pour le jeu de demineur. 

<>° n 

L'acteur principal unique est le joueur. Son cas d'utilisation favori consiste a 
"o « Jouer une partie de demineur ». Neanmoins, il a la possibilite de configurer 
vT* les dimensions du plateau, le nombre initial de mines, etc. N'oublions pas 
egalement le cas d'utilisation « Consulter l'aide en ligne », qui est present 
dans la majorite des applications informatiques interactives ! 



Figure 8-25. 

Diagramme de cas d'utilisation 
du demineur 



lid Use Case Model 



Demineur 





« secondaire » \ 




Configurer le jeu J 




^/ « extend » 




Jouer une partie\ 




de demineur J 




A 

1 r « extend » 




\ « support » \ 




Consulter l'aide J 
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J. 



EXERCICE 8-7. 

Diagramme de sequence systeme 



Developpez un diagramme de sequence systeme pour le cas d'utilisation 
« Jouer une partie de demineur ». 

<>° n 

O Le joueur va passer son temps a decouvrir ou marquer des cases. Dans le cas 
~0 nominal, il va finir par gagner et entrer dans les meilleurs scores (s'il jouait a 
un niveau predefini). On peut done representor tout cela par une grande boucle 
(fragment loop) dans laquelle les operations systeme « marquerCase » et 
« decouvrirCase » peuvent arriver dans un ordre quelconque (d'ou l'operateur 
alt). 



Figure 8-26. 

Diagramme de sequence 
systeme preliminaire 



sd Jouer une partie (simple) 



loop 



opt 

[niveau 



decouvrirCase (pt) 



predefini et meilleurtemps] 
entrerNom(nom) 



« systems 
: Demineur 



an y \ 








[decouvrir] ■ 


decouvri rCase(pt) 










► 




[marquer] ■ 


marquerCase(pt) 











gagne ! 

«C 



Nous pouvons ajouter la configuration du jeu comme une etape optionnelle 
avant de commencer a jouer. La notion de reference vers une occurrence 
d' interaction est tout a fait applicable. 
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Figure 8-27. 

Diagramme de sequence 
systeme complete 



sd Jouer une partie (complete) 



:Joueur 



opt 



ref 



loop 



opt 



Configurer le jeu 



decouvrirCase(pt) 



gagne ! 



[niveai) predefini et meilleur temps] 
1 entrerNom(nom) 



« system » 
: Demineur 



ait y 






[decouvrir] 
[marquer] 


decouvrirCase(pt) 




marquerCase(pt) 





Une solution plus sophistiquee consiste a representer dans la boucle de jeu les 
trois possibilities : perte, gain ou cas normal. Les cas de perte ou gain arretent 
la partie, ce qui peut se representer par l'operateur predefini break. 
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Figure 8-28. 

Diagramme de sequence 
systeme plus sophistique 



sd Jouer une partie (nominal) 



« system 
rDemine 



opt configuration y 



ref y 








Configurer le 


eu 



loop partie ^\ 



alt / 

[mine] 



break ^ 


decouvri rCase(pt) 






perdu ! 








decouvri rCase(pt) 









[decbuvrirl 


decouvri rCase(pt) 


*4 


f< 


affichage contenu 




[marlquer] 


marquerCase{pt) 







ANALYSE ORIENTEE OBJET 



EXERCICE 8-8. 

Modele d'analyse 



Realisez un diagramme de classes d'analyse ainsi qu'un diagramme d'etats si 
necessaire. 



O La principale difficult© consiste a bien representer la double variabilite au 
O niveau des cases : 

vT* • Le fait qu'une case soit minee ou pas est intrinseque a la case et reste vrai 
du debut a la fin de sa vie (nouvelle partie). 
• Le fait qu'une case soit marquee ou pas varie durant sa vie : il s'agit done 
d'une notion d'etat. 
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Le diagramme de classes presente sur le schema suivant doit done etre com- 
plete par un diagramme d'etats de la classe Case. 

Notez egalement qu'une case possede exactement 3 (coin), 5 (bord) ou 8 voi- 
sines 1 . Certains attributs sont calculables done derives, et les coordonnees 
d'une case jouent le role de qualifieur (ou qualificatif). 



Figure 8-29. 

Diagramme de classes 
d'analyse 



Partie 



nbMines Initial: int = 10 
nbMinesRestantes: int 
niveau: Chaine = "debutant" 
resultat: boolean 







J oueur 


nom: 


Chaine 



Chro no metre 




temps: int 





hauteur: int = 
largeur: int = 



I coordonnees I 



voisines 3,5,8 




Figure 8-30. 

Diagramme d'etats 
de la classe Case 



1 



K Decouverte \ 



1 . Nous avons continue a utiliser la notation 3,5,8 pour indiquer les multiplicites discretes des nombres de voisines d'une 
case, bien que cette notation ait ete abandonnee dans UML 2, car jugee trop complexe... 
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CONCEPTION ORIENTEE OBJET AVEC LES DESIGN PATTERNS 



EXERCICE 8-9. 

Conception de I'operation « marquerCase(pt) » 

Realisez les diagrammes de sequence de conception objet pour I'operation 
systeme « marquerCase (pt) ». 

Expliquez vos choix d'utilisation de design patterns si necessaire. 



J- 

O 



Commen9ons par decider quel objet va traiter les operations systeme (voir 
exercice 8-1). Dans notre exemple, l'objet controleur le plus naturel est « Par- 
tie ». L'objet « Partie » n'est pas l'expert des cases ni de leurs coordonnees. II 
va done deleguer le travail a l'expert des cases, soit le « Plateau ». Celui-ci va 
tout d'abord recuperer une reference sur la case dont les coordonnees corres- 
pondent au parametre « pt » de I'operation systeme. Pour cela, il fait appel a 
une collection triee de cases (une Map) pour trouver l'instance « c » corres- 
pondant au parametre « pt ». II va ensuite deleguer a celle-ci le traitement du 
marquage proprement dit. 



sd marquerCase (debut) 



cases : M ap< Point,Case> 



marquerCase (pt) 



marquerCase(pt) 



manjuerQ 



marquerCase (DP State) 



Figure 8-31. 

Debut du diagramme de sequence de conception 
pour I'operation systeme marquerCase(pt) 



Neanmoins, le traitement du marquage depend de l'etat de la case. Si Ton 
veut eviter une logique conditionnelle complexe et peu evolutive, il est inte- 
ressant de deporter le comportement variable dans de nouveaux objets et 
d'utiliser pour cela le design pattern State. 
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A retenir DESIGN PATTERN STATE (ETAT) 

Probleme a resoudre : le comportement d'un objet depend de son etat. 
Cependant, nous n'acceptons pas de cabler en dur cette dynamique dans 
sa classe... 

Solution : utiliser le polymorphisme, mais pas directement par des sous- 
classes de la classe concernee. En effet, un objet ne change pas de classe 
au cours de sa vie. II faut done utiliser le principe de delegation, en creant 
une classe artificielle (pure fabrication) qui recupere le comportement 
variable. Cette classe artificielle sera elle-meme specialised en autant de 
sous-classes que I'objet possede d'etats differents. 

La copie d'ecran suivante montre comment un outil de modelisation UML 
peut integrer les design patterns et permettre de creer facilement les 
classes, attributs, associations et operations concernees. Dans cet 
exemple, I'outil Borland/Together a ainsi cree les elements UML 
generiques, mais aussi le code Java correspondant au design pattern 
State (une interface Etat et des classes concretes par sous-etat, en reco- 
piant toutes les methodes de la classe de depart appelee Context, sans 
oublier de lui ajouter une methode setEtatCourant pour gerer la reference 
au bon etat). 
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Figure 8-32. 

Copie d'ecran de I'outil Borland/Together en pleine action sur le DP State 
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La case va done deleguer a son objet « etatCourant » le comportement variable 
de marquage, conformement au schema suivant. 



sd marquerCase (DP State) 



:EtatDecouverte 



:Eta1Couverte 



:EtatMarquee 



« singleton" 
: Partie 



alt y \ 

[decouverte] 1 

1 marquer(self) 

U *L 


J 


1 g n o re 






[couverte] 


\ marquer(self) 








decrNbMines() | 






setEtatCourant(marquee) 










*v 






[marquee] 




marquer(self) 












setEtatCourant(couverte) 








incrNbMines() 

U 


* 







Figure 8-33. 

Suite du diagramme de sequence de conception pour V operation systeme 
marquerCase(pt) : utilisation du DP State 



Remarquons que de nombreuses classes differentes vont avoir besoin d'un 
acces au controleur Partie, pour decrementer ou incrementer le compteur de 
mines comme indique sur le schema precedent, mais aussi pour signifier la fin 
de la partie (dans le cas de la decouverte d'une case minee). Or, la classe Partie 
ne doit avoir qu'une seule instance a la fois. Assurer qu'une classe ne sera ins- 
tanciee qu'une seule fois et donner un acces global a cette instance unique, tel 
est l'objectif du design pattern Singleton. 
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A retenir DESIGN PATTERN SINGLETON 



Probleme a resoudre : comment garantir I'existence d'une seule instance 
d'une classe donnee et fournir un point d'acces global a cette instance ? 

Solution : sauvegarder I'objet singleton dans une variable de classe 
(statique) et fournir une methode de classe retournant I'instance unique, 
en la creant a la premiere requete. Le constructeur est alors declare prive 
(ou mieux : protege). 
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Figure 8-34. 

Copie d' Scran de Voutil Borland/Together en pleine action sur le DP Singleton 



EXERCICE 8-10. 

Conception de I'operation « decouvrirCase(pt) » 

Realisez les diagrammes de sequence de conception objet pour I'operation 
systeme « decouvrirCase (pt) ». 

3^ 

q Le debut de l'interaction est tres similaire a celle de I'operation systeme 
« marquerCase ». L' objet « Partie » va deleguer le travail a l'expert des cases, 
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soit le « Plateau ». Celui-ci va tout d'abord recuperer une reference sur la 
case dont les coordonnees correspondent au parametre « pt » de l'operation 
sy steme. II va ensuite deleguer a celle-ci le traitement du message 
« decouvrir », qui depend de son etat. 



Figure 8-35. 

Debut du 
diagramme 
de sequence 
de conception 
pour I 'operation 
systeme 

decouvrirCase(pt) 



sd decouv rirCase (debut) 



tPartie 




:Plateau 




cases : 




c :Case 










Map<Point,Case> 








Nous allons utiliser egalement ici le design pattern State. Toutefois cette fois-ci, 
la situation se complique : si la case etait dans l'etat « Couverte », elle passe a 
l'etat « Decouverte », mais le traitement effectue depend maintenant du type de 
case : minee ou pas. La methode « devoiler », appelee par l'etat « Couverte » 
sur la case est elle-meme polymorphe ! 



Figure 8-36. 

Suite du diagramme de 
sequence de conception 
pour I 'operation systeme 
decouvrirCase(pt) .• 
application du DP State 



sd decouv rirCase (DP State) ^ 



:Case 




:EtatDecouverte 




:EtatMarquee 





:EtatCou verte 



[decouverte] 



decouvrir(self) 



gnore 



decouvri r(self) 



decouvri r(self) 



etEtatCou ran t(decou verte) 



devoiler (polymorphe) 
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En effet, devoiler interrompt brutalement la partie sur une case minee. II faut 
alors arreter le chronometre, decouvrir toutes les cases minees et signaler 
toutes les cases marquees a tort avec un X. S'il s'agit d'une case numerotee, 
il faut verifier si la partie n'est pas gagnee (toutes les cases minees sont 
decouvertes) . Enfin, s'il s'agit d'une case vide, il faut propager le message 
« decouvrir » a toutes les voisines 2 . 
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Figure 8-37. 

Fin du diagramme de sequence de conception 
pour I 'operation systeme decouvrirCase(pt) : 
polymorphisme de devoilerO 

EXERCICE 8-11. 

Diagramme de classes de conception 

Dessinez le diagramme de classes de conception objet en indiquant les design 
patterns utilises. 



5> 



on 



O En ajoutant les operations dans les bonnes classes d'apres les diagrammes de 
"o sequence precedents, on obtient assez facilement le schema statique suivant. 



2. Notez le nom de ligne de vie que nous avons employe pour les cases voisines : « voisines[i] : Case ». II s'agit d'une ins- 
tance de la classe Case, selectionnee dans la collection voisines. 

3. Tous les diagrammes de cette etude de cas (sauf les copies d'ecran sur les design patterns) ont ete realises avec l'excel- 
lent outil Enteiprise Architect de Sparx Systems (http://sparxsystems.com.au). 
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Figure 8-38. 

Diagramme 
de classes de 
conception 
du jeu 

de demineur 



cd couche domaine 



line ^ 



«DP Singleton- 
Pa rtie 

nbMineslnitial: int = 10 
jniquelnstance: Partie 
nbMinesRestantes: int 
niveau: Chaine = "debutant" 
resultat: boolean 

marquerCasefpt Point) :void 
decouvrirCasefpt :point) : void 
getlnstanceQ 

if (uniquelnstance == null) 
Partie uniquelnstance = new Partief); 

return uniquelnstance; 
decrNbMinesQ : void 
incrNbMines() : void 
perdreQ : void 
testerSiGagnef) :void 



hauteur: int = 9 
largeur: int = 9 



marque rCase(pt Point) :void 
decouvrirCasefpt Point) :void 



XL 



Chronometre 



start() : void 
stop() :void 



JL 



coordonnees: Point 



marquer() :void 

etatCo u ra nt . m a rq u e r( c) 
decouvrirf) : void 

etatCourant.decouvrir(c) 

devoilerf) : void 

setEtatCourant(e :EtatCase) : void 



devoilerf) : void 
Parti e.perd re 



-etatCourant 



■■DP State- 
EtatCase 



marquer(c :Case) : void 
decouvrirfc :Casej : void 



1 



EtatCouverte 



marquerfc :Case) : void 
decouvrir(c :Case) :void 
c.devoiler 



devoilerf) :void 

loop voisines.decouvrir 



marquerfc :Case) :void 
decouvrirfc :Case) : void 



Case Numerates 



-/ nbVoisinesMinees: 1..8 



devoilerf) : void 
Partie. testerSiGagne 



EtatDecouverte 



marquerfc :Case) : void 
decouvrirfc :Case) :void 



On notera le double arbre d'heritage que le DP State permet d'implementer 
de fa9on modulaire et evolutive. 



CONSEILS METH0D0L0GIQUES 



ARCHITECTURE EN COUCHES 

• Separez votre application en couches. Le principal interet que revet la separation en 
trois couches (3-tiers) est d'isoler la logique metier des classes de presentation (IHM), 
ainsi que d'interdire un acces direct aux donnees stockees par ces classes de presenta- 
tion. Le souci premier est de repondre au critere d'evolutivite : pouvoir modifier 
l'interface de l'application sans devoir modifier les regies metier, et pouvoir changer 
de mecanisme de stockage sans avoir a retoucher l'interface, ni les regies metier. 
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• Pour ameliorer la modularite, introduisez un objet artificiel, appele « controleur », 
entre les objets graphiques et les objets metier. Cet objet de conception connait 
l'interface des objets de la couche metier et joue le role de « facade » vis-a-vis de 
la couche presentation. 

• Dans les cas simples, le controleur peut etre un objet d'une classe d'analyse existante : 

- soit un objet representant le systeme entier ou l'organisation elle-meme ; 

- soit un objet representant un role qui aurait realise l'operation systeme. 

• Decrivez votre architecture en couches par un diagramme statique qui ne montre 
que des packages et leurs dependances. Vous pouvez utiliser le stereotype 
« layer » pour distinguer les packages qui representent les couches. 

• N'oubliez pas que le processus d'analyse/conception est fondamentalement itera- 
tif. L' architecture preliminaire pourra etre affinee ou modifiee (principalement, au 
niveau des partitions a l'interieur de chaque couche) par le travail de conception 
qui va suivre la premiere decoupe d'analyse. 

CONTRAT D'OPERATION 

• Utilisez les contrats d'operations : ils permettent ainsi de faire le lien entre le point 
de vue fonctionnel/dynamique des cas d'utilisation et le point de vue statique 
d'analyse. Un contrat d'operations decrit les changements d'etat du systeme 
quand une operation systeme est effectuee. Ces modifications sont exprimees en 
termes de « post-conditions » qui detaillent le nouvel etat du systeme apres l'exe- 
cution de l'operation. Les principales post-conditions concernent la creation (ou la 
destruction) d'objets et de liens issus du modele statique d'analyse, ainsi que la 
modification de valeurs d'attributs. 

• Utilisez le plan type de description textuelle de contrat d'operations donne ci- 
apres : 

- nom 

- responsabilites 

- references 

- pre-conditions 

- post-conditions 

- exceptions (optionnel) 

- notes (optionnel) 

• Concevez les operations systeme en respectant leur chronologic 

• N'oubliez pas que les post-conditions ne representent que le nouvel etat du sys- 
teme a la fin de l'execution de l'operation systeme. Elles ne sont absolument pas 
ordonnees : c'est le role du concepteur de choisir quel objet doit realiser chaque 
action, et dans quel ordre. 



Conception 

QUATRIEME P ARTIE 



• Pour detailler visuellement une architecture logique, il suffit de recenser toutes les 
classes utilisees dans les differents diagrammes, et de les representer graphique- 
ment a l'interieur du package adequat dans un diagramme de packages. 

DE L'ANALYSE A LA CONCEPTION 

• Pour passer de l'analyse a la conception, utilisez les trois stereotypes de Jacobson 
qui permettent de montrer graphiquement comment un message emis par un 
acteur traverse les couches presentation, application et metier : 

- «boundary» : classes qui servent a modeliser les interactions entre le 
systeme et ses acteurs ; 

- «control» : classes utilisees pour representer la coordination, l'enchaine- 
ment et le controle d'autres objets - elles sont en general reliees a un cas 
d'utilisation particulier ; 

- «ent±ty» : classes qui servent a modeliser des informations durables et 
souvent persistantes. 

• Partez des operations systeme pour initialiser votre etude dynamique sous la 
forme de diagrammes de communication ou de sequence. 

DIAGRAMMES D' INTERACTION DE CONCEPTION 

• Sur les diagrammes de communication, utilisez la numerotation decimale qui per- 
met de montrer l'imbrication des messages, d'une facon comparable a la represen- 
tation des « focus of control » sur le diagramme de sequence. 

• Le diagramme de sequence devient de moins en moins lisible au fur et a mesure 
que Ton ajoute des objets. C'est pour cette raison simple que le diagramme de 
communication est utile en conception : il permet de disposer les objets dans les 
deux dimensions afin d'ameliorer la lisibilite du schema. Le diagramme de com- 
munication presente un autre avantage sur le diagramme de sequence : il permet 
aussi de representer les relations structurelles entre les objets. Par contre, UML2 
permet de representer plus facilement des boucles et des alternatives sur le dia- 
gramme de sequence (fragments loop, alt, opt, etc.) 

• Une idee interessante pour ameliorer la lisibilite du diagramme de communication 
consiste a le decouper en deux en prenant l'objet controleur comme charniere : 

- une premiere partie afin de specifier la cinematique de l'interface homme-machine 
avec les acteurs, les objets «boundary» et l'objet «control» ; 

- une seconde partie afin de specifier la dynamique des couches applicatives et 
metier avec l'objet «control» et les objets «ent±ty». 

• Dans un premier temps, travaillez sur les interactions entre objets « metier », ensuite 
traitez le probleme plus technique de l'initialisation du systeme informatique. Cela 
permet de s'assurer que les bonnes decisions d'affectation de responsabilites aux 
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objets dans le contexte des interactions metier contraignent bien 1' initialisation, et 
pas le contraire. 

DIAGRAMMES DE CLASSES DE CONCEPTION 

• Les diagrammes d'interaction vont permettre d'elaborer des diagrammes de clas- 
ses de conception, et ce en ajoutant principalement les informations suivantes aux 
classes issues du modele d'analyse : 

- les operations : un message ne peut etre recu par un objet que si sa classe a 
declare l'operation publique correspondante ; 

- la navigabilite des associations ou les dependances entre classes, suivant que les 
liens entre objets sont durables ou temporaires, et en fonction du sens de circu- 
lation des messages. 

• Attention : un lien durable entre objets va donner lieu a une association navigable 
entre les classes correspondantes ; un lien temporaire (par parametre : 
« parameter », ou variable locale : « local ») va donner lieu a une simple 
relation de dependance. N'ajoutez pas les classes qui correspondent aux collec- 
tions dans le diagramme de classes de conception, de facon a rester le plus long- 
temps possible independant du langage de programmation cible. 

• Par rapport aux messages des diagrammes d'interaction, ne faites pas apparaitre 
dans les diagrammes de classes de conception : 

- les operations de creation (message create) ; 

- les operations generiques sur les classes conteneurs (addQ, etc.) ; 

- les operations d'acces aux attributs. 

• Vous pouvez utiliser les stereotypes « parameter » et « local » 4 sur les 

dependances entre classes, pour refleter le type de lien temporaire qui existe entre 
les objets correspondants dans le diagramme d'interaction. 

• Conserver un couplage faible est un principe qu'il faut bien avoir a l'esprit pour 
toutes les decisions de conception ; c'est un objectif sous-jacent a evaluer d'une 
facon continue. En effet, en y pourvoyant, on obtient en general une application 
plus evolutive et plus facile a maintenir. 

• N'oubliez pas de faire aussi figurer dans le diagramme de classes celles qui 
n'appartiennent pas au package courant. En effet, il est important de montrer leurs 
relations avec des classes du package courant pour justifier ensuite le sens des 
dependances entre les packages englobants. Precisement, il ne faut representer 
que les associations navigables, les dependances ou les generalisations qui poin- 
tent vers les classes externes a celles du package concerne. 

4. Bien que ces stereotypes semblent avoir disparu du standard dans UML 2, nous continuerons a en preconiser l'utilisation. 
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PASSAGE AU CODE OBJET 

• Les modeles UML de conception permettent de produire aisement du code dans 
un langage de programmation objet tel que Java, C# ou autre : 

- les diagrammes de classes permettent de decrire le squelette du code, a savoir 
toutes les declarations ; 

- les diagrammes d'interaction permettent d'ecrire le corps des methodes, en 
particulier la sequence d'appels de methodes sur les objets qui interagissent. 

• En premiere approche : 

- la classe UML devient une classe Java ou C# ; 

- les attributs UML deviennent des variables d'instances Java ou C# ; 

- les methodes qui permettent l'acces en lecture {get) et en ecriture (set) aux 
attributs, pour respecter le principe d'encapsulation, sont implicites (en C#, on 
utilisera la notion de property) ; 

- les operations UML deviennent des methodes Java ou C# ; 

- les roles navigables produisent des variables d'instances, tout comme les attri- 
buts, mais avec un type utilisateur au lieu d'un type simple ; 

- le constructeur par defaut est implicite. 

• N'oubliez pas la directive d'importation (ou d'utilisation) pour les relations avec 
les classes qui appartiennent a d'autres packages, ainsi que pour les classes de 
base Java ou C#. 

• Comment traduire les associations navigables de multiplicite « * » ? Utilisez un 
attribut de type collection de references d'objets au lieu d'une simple reference sur 
un objet. La difficulte consiste a choisir la bonne collection parmi les tres nombreu- 
ses classes de base que proposent Java et C#. Bien qu'il soit possible de creer des 
tableaux d'objets, ce n'est pas forcement la bonne solution. En la matiere, on prefere 
plutot recourir a des collections, parmi lesquelles les plus utilisees sont : 

- En Java : Array List (anciennement Vector) et HashMap (anciennement HashTable). 
Utilisez ArrayList si vous devez respecter un ordre et recuperer les objets a 
partir d'un indice entier ; utilisez HashMap si vous souhaitez recuperer les 
objets a partir d'une cle arbitraire. 

- En C# : ArrayList, SortedList et HashTable. Utilisez ArrayList si vous devez respecter 
un ordre et recuperer les objets a partir d'un indice entier ; utilisez HashTable ou 
SortedList si vous souhaitez recuperer les objets a partir d'une cle arbitraire. 

- N'hesitez pas a utiliser les collections typees (generics) si votre langage le permet 
(Java 1.5, C# 2.0, etc.). 

DIAGRAMME DE DEPLOYMENT 

• Decrivez l'implantation physique de votre application grace au diagramme de 
deploiement. 
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• Utilisez-le pour montrer la configuration physique des differents materiels qui 
participent a l'execution du systeme, ainsi que les artefacts qu'ils supportent. 

• Un artefact modelise une entite physique comme un fichier. On le represente 
par un rectangle contenant le mot-cle « artifact ». On explicite la presence d'un 
artefact sur un nceud de deploiement en imbriquant son symbole dans celui du 
nceud englobant. 

DESIGN PATTERNS 

• Nous vous conseillons de passer du temps a etudier les fameux « Design 
Patterns ». 

• Maitrisez en particulier au moins les DP Composite, Observateur, Strategic, 
Singleton, Template Method, Adapteur, Facade et Fabrique abstraite. 

• N'abusez cependant pas des design patterns ! N'oubliez pas que vous ne devez les 
appliquer que lorsque vous avez besoin d'isoler un point de variabilite. Le risque 
est important sinon de complexifier inutilement vos conceptions. 



Conclusion 



Nous avons done termine cette premiere visite guidee dans le monde merveilleux de la 
conception orientee objet ! II y aurait encore bien d'autres sujets a evoquer, entre autres, 
la conception d'interfaces homme-machine, la gestion de la persistance, la distribution 
de composants. Si vous souhaitez approfondir certains de ces themes, vous pourrez vous 
reporter a la bibliographic qui est presentee en annexe 5 . 



5 . On trouve egalement de nombreuses ressources utiles sur le Web : 

• www.hillside.net/patterns (le site officiel des design patterns...) 

• www.dotnetguru.org (un tres bon site francais sur la plate-forme .NET, C#, etc.) 

• www.therationaledge.com (un magazine gratuit en ligne...) 

• www.jot.fm (pointu, mais tres interessant, en particulier la serie d'articles sur UML 2.0 par Conrad Bock) 




Correspondances 
UML - Java - C# 



UML est un langage de modelisation visuelle, Java et C# 
sont des langages de programmation textuels. UML est plus 
riche que les langages de programmation dans le sens ou il 
offre des moyens d'expression plus abstraits et plus puis- 
sants. Cependant, il existe generalement une facon privile- 
giee de traduire les concepts UML en declarations Java 
ou C# (nous avons egalement essaye de respecter les con- 
ventions de nommage de chaque langage). 

Cette annexe vous propose une synthese des correspondan- 
ces importantes entre les concepts de modelisation UML et 
le monde de I'implementation dans un langage oriente 
objet 1 . 



1 . Pour un approfondissement des differences entre les langages Java et C#, allez faire un tour sur www.dotnetguru.org. 
Vous y trouverez en particulier un article intitule : « L'essentiel de C# versus Java » 
(ww w.dotnetguru .org/article .php?sid= 18) 
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I Annexes 

La structure statique 



Les concepts structuraux (ou statiques) tels que classes et interfaces sont fondamentaux 
aussi bien en UML qu'en Java ou C#. lis sont representee en UML dans les diagrammes 
de classes, et constituent le squelette d'un code oriente objet. 

CLASSE 

La classe est le concept fondamental de toute technologie objet. Le mot-cle correspon- 
dant existe aussi bien en Java qu'en C#. 

Par defaut chaque classe UML devient un fichier java (Java) ou .cs (C#). 



UML 


Java 




Catalogue 




public class Catalogue { 
} 




C# 


public class Catalogue { 
} 



Une classe abstraite est simplement une classe qui ne s'instancie pas directement mais 
qui represente une pure abstraction afin de factoriser des proprietes. Elle se note en 
itolique. 



UML 


Java 




Personne 




abstract public class Personne { 
} 






C# 


abstract public class Personne { 
} 



INTERFACE 

La notion UML d'interface (representee sous ses deux formes graphiques) se traduit par 
le mot-cle correspondant aussi bien en Java qu'en C#. 
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UML 


Java 




interface lAffichable { 






«interface» 
lAffichable 




void afficher () ; 

} 


















C# 




+afficher() 










interface lAffichable { 
void Afficher () ; 

} 


O 

lAffichable 



PACKAGE 

Le package en tant que regroupement de classes ou d'interfaces existe aussi bien en Java 
qu'en C#, mais avec une syntaxe differente. 



UML 


Java 






package catalogue; 




Catalogue 




c# 














namespace Catalogue 
{ 






} 



ATTRIBUT 

Les attributs deviennent des variables en Java et en C# 2 . Leur type est soit un type 
primitif (int, etc.), soit une classe fournie par la plate-forme (String, Date, 
etc.)- Attention a ne pas oublier dans ce cas la directive d' importation du package 
correspondant. 

La visibilite des attributs est montree en les faisant preceder par + pour public, #pour 
protege (protected), - pour prive (private). 

Les attributs de classe en UML deviennent des membres statiques en Java ou en C#. 

Les attributs de type reference a un autre objet ou a une collection d'objets sont discutes 
dans la section « Association ». 



2. Comme indique au chapitre 7 (exercice 7-29), on pourra utiliser egalement en C# le concept de « property ». 
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UML 



Catalogue 



-nom:String 
-dateCreation:Date 



Java 



import java.util .Date; 



public class Catalogue { 
private String nom; 
private Date dateCreation; 



} 



c# 



using System; 

public class Catalogue { 
private string nom; 
private DateTime dateCreation; 



} 



UML 



Java 



Personne 



-nom:String 
-prenom:String 
#dateNaissance : Date 

-aqpMajnritP-int=ia 



abstract public class Personne { 
private String nom; 
private String prenom; 
protected Date dateNaissance; 
private static int ageMajorite 

} 



18; 



C# 



abstract public class Personne { 
private string nom; 
private string prenom; 
protected DateTime dateNaissance ; 
private static int ageMajorite = 18; 

} 



OPERATION 

Les operations deviennent des methodes en Java et en C#. 

Leur visibilite est definie avec les memes conventions que les attributs. 

Les operations de classe deviennent des methodes statiques ; les operations abstraites 
(en italique) se traduisent par le mot-cle correspondant en Java ou en C#. 
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UML 



Catalogue 



-nom:String 
-dateCreation:Date 



+chercherl_ivre(isbn:ISBN):l_ivre 



Java 

public class Catalogue { 
private String nom; 
private Date dateCreation; 
public Livre chercherLivre (ISBN isbn) { 



} 



c# 



public class Catalogue { 
private string nom; 
private DateTime dateCreation; 
public Livre ChercherLivre (ISBN isbn) { 



} 



UML 



Java 



Personne 



-nom:String 
-prenom:String 
#dateNaissance:Date 
- ageMaiorite:int=18 



+calculerDureePret():int 

+setAqeMaiorite(a:int) 

+getAge():int 



abstract public class Personne { 
private String nom; 
private String prenom; 
protected Date dateNaissance ; 
private static int ageMajorite = 18; 
public abstract int calculerDureePret () ; 
public static void setAgeMajorite (int aMaj) { 



} 



public int getAge() { 



c# 



abstract public class Personne { 
private string nom; 
private string prenom; 
protected DateTime dateNaissance; 
private static int ageMajorite = 18; 
public abstract int CalculerDureePret () ; 
public static void SetAgeMajorite (int aMaj) { 



} 



public int GetAge() { 
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Les relations 



Les relations UML entre concepts statiques sont tres riches et ne se traduisent pas toutes 
de facon simple par un mot-cle dans les langages objet Java ou C#. 



GENERALISATION 



Le concept UML de generalisation se traduit directement par le mecanisme de l'heritage 
dans les langages objet. La syntaxe est differente en Java et en C#. 



UML 



Personne 



-nom:String 

-prenom:String 

-dateNaissance:Date 



7T 



Adherent 



-iD:int 



Java 



public class Adherent extends Personne { 
private int iD; 

} 



C# 



public class Adherent 
private int iD; 

} 



Personne { 



REALISATION 



Une classe UML peut implementer plusieurs interfaces. Contrairement a C++, les 
langages Java et C# proposent directement ce mecanisme, mais pas l'heritage multiple 
entre classes. 

C# utilise la syntaxe du C++ pour l'heritage. Le meme mot-cle s'utilise pour l'heritage 
d'implementation et d'interface contrairement a Java qui specifie extends et imple- 
ments. 
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UML 



«interface» 
lEmpruntable 



+emprunter():void 
+retourner():void 



T 



«interface» 
llmprimable 



+imprimer():void 



4 



Livre 



-titre:String 

-auteunString 

■isbn:ISBN 



+imprimer():void 

+emprunter():void 

+retourner():void 



Java 

public class Livre implements 
llmprimable, lEmpruntable { 
private String titre; 
private String auteur; 
private ISBN isbn; 
public void imprimer () { 



} 



public void emprunter(){ 



public void retourner(){ 



c# 



public class Livre : 
llmprimable, lEmpruntable { 
private string titre; 
private string auteur; 
private ISBN isbn; 
public void Imprimer () { 



} 



public void Emprunter(){ 



public void Retourner(){ 



DEPENDANCE 

La dependance est un concept tres general en UML. 

Une dependance entre une classe A et une classe B existe par exemple si A possede une 
methode prenant comme parametre une reference sur une instance de B , ou si A utilise 
une operation de classe de B . II n'existe pas de mot-cle correspondant en Java ou en C#. 

La dependance entre packages se traduit de facon indirecte par des directives d'importa- 
tion ou d'usage en Java et en C#. 
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Bibliotheque 



+Bibliotheque 



Catalogue 



+Catalogue 
+Livre 



UML 



HndiquerEmprunteur(iD:ini):void 



Catalogue.Catalogue 



-lesLivres:Livre 

-nom:String 

-d ateC reation : Date 



-chercherLivre(i5bn:ISBN):Livre 



Java 

package bibliotheque; 

import catalogue; 

public class Bibliotheque { 

private Catalogue leCatalogue; 



} 



c# 



namespace Bibliotheque 
{ 

using Cataloguer- 
public class Bibliotheque { 

private Catalogue leCatalogue; 



} 



ASSOCIATION 

Les associations navigables se traduisent par du code Java ou C# qui depend notamment 
de la multiplicite de l'extremite concernee, mais aussi de l'existence d'une contrainte 
{ ordered } ou d'un quaMcatif . 

Une association navigable avec une multiplicite 1 se traduit par une variable d'instance, 
tout comme un attribut, mais avec un type reference vers une instance de classe du 
modele au lieu d'un type simple. 

Une multiplicite « * » va se traduire par un attribut de type collection de references d'objets 
au lieu d'une simple reference sur un objet. La difficulte consiste a choisir la bonne collec- 
tion parmi les tres nombreuses classes de base que proposent Java et C#. Bien qu'il soit 
possible de creer des tableaux d'objets, ce n'est pas forcement la bonne solution. En la 
matiere, on prefere plutot recourir a des collections, parmi lesquelles les plus utilisees sont : 

• En Java : ArrayList (anciennement Vector) et HashMap (anciennement HashTa- 
ble). Utilisez ArrayList si vous devez respecter un ordre et recuperer les objets a 
partir d'un indice entier ; utilisez HashMap si vous souhaitez recuperer les objets 
a partir d'une cle arbitraire 3 . 

• En C# : ArrayList, SortedList et HashTable. Utilisez ArrayList si vous devez respec- 
ter un ordre et recuperer les objets a partir d'un indice entier ; utilisez HashTable ou 
SortedList si vous souhaitez recuperer les objets a partir d'une cle arbitraire. 

3. Attention, le JDK 1.5 introduit les collections typees appelees « generics ». Nous allons les utiliser pour affiner la figure 
concernee sur la traduction des associations. 
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UML 



A1 




,B1 



A2 




\B2 





Java 

public class Al { 

private Bl leBl; 



public class A2 { 

private B2 lesB2[]; 



} 



public class A3 { 

private List<B3> lesB3 
= new ArrayList<B3> () ; 



} 



public class A4 { 

private Map<Q,B4> lesB4 
= new HashMap<Q, B4> () ; 



> 



Of 

public class Al { 

private Bl leBl; 



public class A2 { 

private B2[] lesB2; 



} 



public class A3 { 

private ArrayList lesB3 
= new ArrayList () ; 



} 



public class A4 { 

private HashTable lesB4 
= new HashTable () ; 



Une association bidirectionnelle se traduit simplement par une paire de references, une 
dans chaque classe impliquee dans l'association. Les noms des roles aux extremites 
d'une association servent a nommer les variables de type reference. 



UML 



Java 



C# 



Homme 



0..1 mari 



0..1 



epouse 



Femme 



public class Homme { 

private Femme epouse; 



} 



public class Femme { 

private Homme mari; 



} 



public class Homme { 

private Femme epouse; 



} 



public class Femme { 

private Homme mari; 



} 
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Une association reflexive se traduit simplement par une reference sur un objet de la 
meme classe. 



UML 



Personne 



subordonne 0..* 



Java 

public class Personne { 

private Personne subordonne [] ; 
private Personne chef ; 



} 



c# 



public class Personne { 

private Personnel] subordonne; 
private Personne chef ; 



} 



AGREGATION ET COMPOSITION 

L agregation est un cas particulier d'association non symetrique exprimant une relation 
de contenance. Les agregations n'ont pas besoin d'etre nominees : implicitement elles 
signifient «contient», « est compose de». La semantique des agregations n'est pas 
fondamentalement differente de celle des associations simples, elles se traduisent done 
comme indique precedemment en Java ou en C#. La seule contrainte est qu'une associa- 
tion ne peut contenir de marque d'agregation qu'a l'une de ses extremites. 

Une composition est une agregation plus forte impliquant que : 

• une partie ne peut appartenir qu'a un seul composite (agregation non partagee) ; 

• la destruction du composite entraine la destruction de toutes ses parties (le compo- 
site est responsable du cycle de vie des parties). 

Dans certains langages objet, par exemple C++, la composition implique la propagation 
du destructeur, mais cela ne s' applique ni a Java ni a C#. 

Par contre, la notion de classe imbriquee peut s'averer interessante pour traduire la 
composition. Elle n'est cependant pas du tout obligatoire. 
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UML 


Java 


C# 




Vo 

-model 

< 

1\ 
Mot 

-puissa 


ture 

s:String 

/ 

eur 

ice:int 


public class Voiture { 

private String models; 
private Moteur moteur; 
private static class Moteur { 
private int puissance; 

) 

} 


public class Voiture { 

private string modele; 
private Moteur moteur; 
private class Moteur { 

private int puissance; 

} 

) 



CLASSE DISSOCIATION 



II s'agit d'une association promue au rang de classe. Elle possede tout a la fois les 
caracteristiques d'une association et d'une classe et peut done porter des attributs qui 
se valorisent pour chaque lien. Ce concept UML avance n'existe pas dans les langages 
de programmation objet, il faut done le traduire en le transformant en classe normale, 
et en ajoutant des variables de type reference. 



UML 



Personne 



employe 



employeur 



0..* 



Emploi 



titre : String 
salaire : double 



Societe 



Java 

public class Emploi { 

private String titre; 
private double salaire; 
private Personne employe; 
private Societe employeur 



} 



c# 



public class Emploi { 

private string titre; 
private double salaire; 
private Personne employe; 
private Societe employeur 



} 
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Le glossaire qui suit est, pour une part importante, librement inspire du document de 
l'OMG specifiant UML 2.1. Chaque entree de glossaire est suivie par son intitule 
original en anglais (americain), s'il y a lieu. 



ACTEUR Construction qui represente un role joue par un utilisateur humain ou un 
(ACTOR) autre systeme qui interagit directement avec le systeme etudie. Un acteur 
participe a au moins un cas d' utilisation. 

ACTEUR METIER Acteur stereotype qui represente une entite externe a l'entreprise (dans le 
(BUSINESS ACTOR) ca dre de l'extension d'UML pour la modelisation metier). 

ACTEUR PRINCIPAL Acteur pour qui le cas d'utilisation concerne produit un resultat observable 
(PRIMARY ACTOR) (p ar opposition a acteur secondaire) . Le titre du cas d'utilisation doit cor- 
respondre a l'objectif de l'acteur principal. 

ACTEUR SECONDAIRE Acteur qui n'est que sollicite par le systeme lors du cas d'utilisation concerne, 
(SECONDARY ACTOR) ou q U i en retire un resultat secondaire (par opposition a acteur principal) . 

ACTION Unite fondamentale de specification comportementale qui represente un 
traitement ou une transformation. Les actions sont contenues dans les acti- 
vites, qui fournissent leur contexte. 

ACTIVITE Specification d'un comportement parametre qui est exprime par un flot 
(ACTIVITY) d'execution via une sequence d'unites subordonnees (dont les elements 
primitifs sont des actions individuelles). 

ACTIVITE CONTINUE Activite durable qui ne s'arrete que lorsque se produit un evenement qui 
fait sortir l'objet de l'etat englobant. 

ACTIVITE FINIE Activite durable qui peut etre interrompue par un evenement, mais s'arrete 
de toute fa^on d'elle-meme au bout d'un certain temps, ou quand une cer- 
taine condition est remplie . 
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AGREGATION Forme d'association non symetrique qui exprime un couplage fort et une 
(AGGREGATION) relation de subordination. 



ARCHITECTURE Ensemble des decisions significatives ayant trait a l'organisation d'un sys- 
teme logiciel, a la selection des elements structurels dont le systeme est 
compose et de leurs interfaces, ainsi qu'a leur comportement tel qu'il est 
specifie dans les collaborations entre ces elements. 

1) En analyse : vue de l'architecture d'un systeme comprenant les classes 
d'analyse, les packages d'analyse et les realisations de cas d'utilisation ; 
vue qui, pour l'essentiel, affine et structure les besoins du systeme. 

2) En conception : vue de l'architecture d'un systeme comprenant les clas- 
ses de conception, les sous-systemes de conception, les interfaces et les 
realisations de cas d'utilisation qui constituent le vocabulaire du domaine 
de la solution du systeme. 



Architecture 
logique 



Artefact 

(Artifact) 

Association 



asynchrone 

(Asynchronous) 



Specification d'un element physique d'information (modele, fichier ou 
logiciel) pouvant etre lie a un composant et deploye sur un nceud . 

Relation entre classifieurs (classes, cas d'utilisation, etc.), qui decrit un 
ensemble de liens entre instances. 

Forme de communication non bloquante et sans accuse de reception. 



ATTRIBUT (ATTRIBUTE) Propriete structurelle d'un classifieur qui caracterise ses instances. Plus 
simplement, donnee declaree au niveau d'une classe et valorisee par cha- 
cun des objets de cette classe. 



attribut derive 

(derived attribute) 



Cas d'utilisation 

(use case) 



Attribut interessant pour l'analyste, quoique redondant car sa valeur peut 
etre deduite d'autres informations disponibles dans le modele. 

Un cas d'utilisation represente un ensemble de sequences d'actions qui 
sont realisees par le systeme et qui produisent un resultat observable 
interessant pour un acteur particulier. On peut egalement le voir comme 
une collection de scenarios relies par un objectif utilisateur commun. 

CLASSE (CLASS) Description abstraite d'un ensemble d'objets qui partagent les memes 
proprietes (attributs et associations), comportements (operations et etats) 
et semantique. 

Classe qui ne s'instancie pas directement (par opposition a une classe 
concrete). Elle sert en general a factoriser des proprietes communes a un 
certain nombre de sous-classes. 



Classe abstraite 

(abstract class) 



Classe concrete 

(concrete class) 

Classe d'association 

(Association class) 



Par opposition a une classe abstraite, classe qui s'instancie directement 
pour donner des objets. 

Association promue au rang de classe. Elle possede tout a la fois les carac- 
teristiques d'une association et d'une classe. Permet de decrire des attributs 
qui se valorisent pour des liens et non pas pour des objets. 
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CLASSE STRUCTUREE Classe contenant des parties, des connecteurs et des ports qui definissent 
(Structured class) sa structure interne. 

COLLABORATION Vue ou projection d'un ensemble de classifieurs cooperants. Une collabo- 
ration decrit les liens et les proprietes requis entre des instances qui jouent 
les roles de la collaboration. Plusieurs collaborations peuvent decrire diffe- 
rentes projections du meme ensemble de classifieurs. 



Collection 



Composant 

(component) 

Composition 



Conception 

(design) 

Condition (de garde) 

(guard condition) 

Connecteur 

(connector) 



Constructeur 

(constructor) 

Contrainte 

(constraint) 



Contrat 
d'operation 

(operation contract) 



controleur 

(controler) 

couche (layer) 
couplage (coupling) 



Dependance 

(dependency) 



Terme generique qui designe tous les regroupements d'objets sans preciser 
la nature du regroupement. 

Partie modulaire d'un systeme qui encapsule son contenu. Un composant 
definit son comportement en termes d'interfaces fournies et requises. 

Forme forte d'agregation, dans laquelle les parties ne peuvent appartenir a 
plusieurs agregats et ou le cycle de vie des parties est subordonne a celui 
de l'agregat. 

Determination du comment d'une application (par opposition a l'analyse 
qui specifie le quoi). 

Expression booleenne qui doit etre vraie pour que la transition qui la porte 
soit validee lorsque l'evenement declencheur se produit. 

Relation contextuelle entre des parties dans le contexte d'une classe struc- 
turee. Contrairement a une association, il s'agit d'une relation entre des 
roles mais pas entre des classes qui sont les types de roles declares. 

Operation de classe qui construit des objets. 

Relation semantique entre elements de modelisation qui definit une condi- 
tion qui doit etre verifiee par les elements concernes. Elle peut etre expri- 
mee en texte libre ou dans une notation plus formelle. 

Description des changements d'etats du systeme quand une operation 
systeme est effectuee. Ces modifications sont exprimees en termes de 
« post-conditions » qui detaillent le nouvel etat du systeme apres l'exe- 
cution de 1' operation. 

Objet artificiel introduit pour separer les couches logicielles 
« Presentation » et « Metier » . 

Segmentation horizontale des modeles. 

1) Dependance entre elements de modelisation. 

2) Le « couplage » represente une mesure de la quantite d'autres classes 
auxquelles une classe donnee est connectee, dont elle a connaissance, ou 
dont elle depend. 

Relation semantique entre deux elements, dans laquelle la modification 
d'un des elements (l'element independant) peut affecter la semantique de 
l'autre element (l'element dependant). 



UML 2 par la pratique 

Annexes 



Deployment 

(deployment) 

Entite metier 

(business entity) 



Erreur 
(ou exception) 

essentiel 

(essential) 

Etat 

(state) 



evenement 

(event) 

evenement interne 

(change event) 



evenement temporel 

(time event) 

Extension 



Factorisation 



Generalisation 

(generalization) 



Generalisation 
multiple 

Heritage 

(inheritance) 



identite 

(identity) 

Importation 



Inclusion 



Le deploiement montre la configuration physique des differents materiels qui 
participent a l'execution du systeme, ainsi que les artefacts qu'ils supportent. 

Classe stereotypee qui represente une entite passive, manipulee par un tra- 
vailleur metier (dans le cadre de l'extension d'UML pour la modelisation 
metier). 

Evenement qui provoque la terminaison prematuree d'un cas d'utilisation 
et qui empeche d'atteindre les post-conditions. 

Se dit d'un cas d'utilisation analytique, independant de toute technologie 
d'interfacage avec les acteurs. 

Condition ou situation qui se produit dans la vie d'un objet pendant 
laquelle il satisfait une certaine condition, execute une activite particuliere 
ou attend certains evenements . 

Specification d'une occurrence remarquable qui a une localisation dans le 
temps et l'espace. Un evenement peut declencher une transition dans le 
contexte des diagrammes d'etats. 

Formalise par le pseudo-evenement « when » suivi d'une expression boo- 
leenne en argument : la transition est declenchee lorsque la condition passe 
de faux a vrai . 

Formalise par le pseudo-evenement « after » suivi d'une duree en argu- 
ment qui represente l'echeance d'un timer. 

Relation stereotypee extend entre cas d'utilisation : le cas d'utilisation 
de base en incorpore implicitement un autre, de facon optionnelle, a un 
endroit specifie indirectement dans celui qui precede a l'extension. 

Identification puis extraction de similitudes entre classes au moyen d'une 
superclasse. 

Relation entre classifieurs ou les descendants heritent les proprietes de leur 
parent commun. lis peuvent neanmoins comprendre chacun des proprietes 
specifiques supplementaires, mais aussi modifier les comportements herites. 

Forme de generalisation dans laquelle une classe derive de plusieurs super- 
classes. Souvent synonyme d'heritage multiple. 

Mecanisme par lequel des elements plus specifiques recuperent automati- 
quement la structure et le comportement d'elements plus generaux ; prin- 
cipal technique de realisation de la generalisation. 

Caracteristique intrinseque d'un objet qui le distingue de tous les autres 
objets. 

Relation de dependance entre packages qui rend visibles les elements 
publics d'un package au sein d'un autre package. 

Relation stereotypee « include » entre cas d'utilisation : le cas d'utilisa- 
tion de base en incorpore explicitement un autre, de facon obligatoire, a un 
endroit specifie dans ses enchainements . 
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Interface 



Lien 

(link) 

LlGNE DE VIE 

(lifeline) 
Message 



INSTANCE Une entite possedant une identite unique, creee a partir d'un classifieur (un 
objet est une instance d'une classe). 

Partie visible d'une classe ou d'un package ; parfois synonyme de specifi- 
cation ou de vue externe, ou encore de vue publique. Ensemble nomme 
d'operations qui caracterise le comportement d'un element. 

Connexion semantique entre objets par laquelle un objet peut communi- 
quer avec un autre objet par envoi de message. Une instance d' association. 

Representation de l'existence d'un element participant dans un diagramme 
de sequence. 

Element de communication unidirectionnel entre objets qui declenche une 
activite dans l'objet destinataire. La reception d'un message provoque un 
evenement dans l'objet recepteur. 

Utilise dans les diagrammes de sequence systeme pour representer les 
interactions entre les acteurs et le systeme vu comme une boite noire. 

Realisation d'une operation. Elle specifie l'algorithme ou la procedure 
associee a 1' operation. 

Modelisation des processus, des ressources et de l'organisation d'une 
entreprise, en amont de toute informatisation. Fait l'objet d'une extension 
a UML proposee par I. Jacobson. 

Decrit le nombre d'objets (min et max) qui peuvent participer a une rela- 
tion avec un autre objet dans le cadre d'une association. Plus generale- 
ment, une multiplicite est un sous-ensemble des entiers non negatifs. 

Qualite d'une association qui permet le passage d'une classe a l'autre dans 
une direction donnee. 

Element physique existant a l'execution et representant une ressource de 
calcul, dote en principe au moins de memoire et souvent de capacites de 
traitement. 

OBJET (OBJECT) Entite aux frontieres bien definies possedant une identite et encapsulant un 
etat et un comportement ; un objet est une instance d'une classe. 

Element de comportement des objets, defini de maniere globale dans la 
classe. Specification d'une methode. 

Comportement de niveau systeme, declenche par un message provenant 
d'un acteur (par analogie a une operation au niveau d'un objet, declenchee 
par une reception de message provenant d'un autre objet). 

PACKAGE Mecanisme general de regroupement d'elements en UML, qui peut etre uti- 
lise par exemple pour regrouper des cas d'utilisation, ou des classes et des 
associations. Les packages peuvent etre imbriques dans d'autres packages. 

PARTICIPANT (PART) Fragment structure d'une classe qui decrit le role joue par une instance 
dans le contexte de la classe structured. Un participant possede un nom, un 
type et une multiplicite. 



Methode 

(method) 

Modelisation metier 

(business modeling) 



Multiplicite 

(multiplicity) 



Navigabilite 

(navigability) 

Nceud 

(node) 



Operation 

(operation) 

Operation systeme 

(system operation) 
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PATTERN Solution de modelisation recurrente et documented, applicable dans un 
contexte donne. En UML, il s'agit d'une collaboration parametree. 

PORT Point d'interaction individuel entre une classe et son environnement. Dans 
une classe structured, on peut connecter les ports a des participants internes 
ou a la specification de comportement de l'objet dans son ensemble. 

POST-CONDITION Condition booleenne qui devient vraie pour le systeme a la fin de l'execution 
d'un cas d'utilisation, sauf pour les scenarios d'erreur. Egalement utilised 
pour specifier dans une operation la condition booleenne qui doit etre vraie 
apres l'execution de l'operation. 

PRE-CONDITION Condition booleenne qui doit etre vraie pour que l'execution d'un cas 
d'utilisation puisse demarrer ; ou avant l'execution d'une operation. 

PRIVE (PRIVATE) Invisible de l'exterieur d'une classe (ou d'un package). 

PROCESSUS METIER Cas d'utilisation stereotype qui permet de representer un processus d'entre- 
(BUSINESS USE CASE] prise (dans le cadre de l'extension d'UML pour la modelisation metier). 

PSEUDO-ETAT Designe des etats particuliers dans le cadre du diagramme d'etats, comme 
(PSEUDO-STATE) 1'etat initial, l'etat final et l'historique. 

PUBLIC Visible de l'exterieur d'une classe (ou d'un package). 

QUALIFICATIF Attribut qui permet de « partitionner » l'ensemble des objets en relation 
(QUALIFIER) avec un objet donne dans le cadre d'une association multiple. 

REEL Se dit d'un cas d'utilisation decrit du point de vue de la conception, en ter- 
(REAL) mes d'evenements d'interface utilisateur, d'entreds de donneds, etc. 

REFLEXIVE Se dit d'une association dont les roles concernent la meme classe. 

REGION CONCURRENTE Ensemble de sous-etats exclusifs qui peuvent exister simultanement avec 
(CONCURRENT REGION) d'autres sous-etats contenus dans le meme super-etat. 

ROLE Nom donne a une extremite d'une association ; par extension, maniere 
dont les instances d'une classe voient les instances d'une autre classe au 
travers d'une association. 

SCENARIO Une succession particuliere d'enchainements, qui s'execute du debut a la 
fin du cas d'utilisation. On distingue classiquement le scenario nominal, 
les scenarios alternatifs et ceux d'erreur. 

SIGNATURE Identifiant non ambigu d'une operation, construit a partir du nom de l'ope- 
ration et de ses parametres (ainsi que de son parametre de retour optionnel) . 

SOUS-CLASSE Classe specialised, reliee a une autre classe plus generale par une relation 

(SUBCLASS) d e generalisation. 

SOUS-ETAT Etat englobe dans un super-etat. Les sous-etats peuvent etre sequentiels ou 

(SUBSTATE) concurrents. 

SPECIALISATION Point de vue descendant porte sur une classification, par opposition a 
(SPECIALIZATION) generalisation. 



Glossaire 



Annexe 2 



STEREOTYPE Creation d'un nouvel element de modelisation par extension de la seman- 
tique d'un element existant du metamodele UML. 

SlIPER-CLASSE Classe generale reliee a une autre classe plus specialised par une relation 
de generalisation. 

SUPER-ETAT Etat composite qui contient des sous-etats. 

SYNCHRONE Forme de communication bloquante, avec accuse de reception implicite. 

(synchronous) 

TRANSITION Connexion entre deux etats d'un automate, qui est declenchee par P occur- 
rence d'un evenement, et conditionnee par une condition de garde, indui- 
sant certaines activites. 

TRANSITION Transition sans evenement declencheur explicite. Represente la terminai- 

AUTOMATIQUE son de l'activite durable finie de l'etat de depart. 

(completion transition) 

TRANSITION INTERNE Transition sans etat d'arrivee. Represente une reponse a un evenement 

(INTERNAL transition) sans changement d'etat. 

TRANSITION PROPRE Transition pour laquelle l'etat d'arrivee est le meme que l'etat de depart. 
(SELF TRANSITION) Provoque neanmoins une sortie de l'etat puis une rentree dans ce meme 
etat, ce qui declenche les eventuels effets de sortie et d'entree. 

TRAVAILLEUR METIER Classe stereotypee qui represente un humain agissant a l'interieur de 

(BUSINESS WORKER) l'entreprise (dans le cadre de l'extension d'UML pour la modelisation 
metier) . 

UNITE Package stereotype qui structure le modele metier (dans le cadre de 

□'ORGANISATION l'extension d'UML pour la modelisation metier). 

(ORGANIZATION UNIT) 

VlSIBILITE Niveau d' encapsulation des attributs et des operations dans les classes (en 

(VISIBILITY) standard : public, protege ou prive). 
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Puisse chaque disciple prendre soin de ne pas s 'attacher aux 
mots comme s'ils exprimaient parfaitement le sens. Lorsqu'un 
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et les simples d' esprit sont comme des enfants, incapables de 
renoncer a cette idee que la vraie signification est contenue dans 

le bout-du-doigt des mots. 



Lanka vatara Sutra 



Le mieux est Vennemi du bien. 

Voltaire 
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